Podcasts about ECMAScript

Francois Daost is a W3C staff member and co-chair of the Web Developer Experience Community Group. We discuss the W3C's role and what it's like to go through the browser standardization process. Related links W3C TC39 Internet Engineering Task Force Web Hypertext Application Technology Working Group (WHATWG) Horizontal Groups Alliance for Open Media What is MPEG-DASH? | HLS vs. DASH Information about W3C and Encrypted Media Extensions (EME) Widevine PlayReady Media Source API Encrypted Media Extensions API requestVideoFrameCallback() Business Benefits of the W3C Patent Policy web.dev Baseline Portable Network Graphics Specification Internet Explorer 6 CSS Vendor Prefix WebRTC Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: today I'm talking to Francois Daoust. He's a staff member at the W3C. And we're gonna talk about the W3C and the recommendation process and discuss, Francois's experience with, with how these features end up in our browsers. [00:00:16] Jeremy: So, Francois, welcome [00:00:18] Francois: Thank you Jeremy and uh, many thanks for the invitation. I'm really thrilled to be part of this podcast. What's the W3C? [00:00:26] Jeremy: I think many of our listeners will have heard about the W3C, but they may not actually know what it is. So could you start by explaining what it is? [00:00:37] Francois: Sure. So W3C stands for the Worldwide Web Consortium. It's a standardization organization. I guess that's how people should think about W3C. it was created in 1994. I, by, uh, Tim Berners Lee, who was the inventor of the web. Tim Berners Lee was the, director of W3C for a long, long time. [00:01:00] Francois: He retired not long ago, a few years back. and W3C is, has, uh, a number of, uh. Properties, let's say first the goal is to produce royalty free standards, and that's very important. Uh, we want to make sure that, uh, the standard that get produced can be used and implemented without having to pay, fees to anyone. [00:01:23] Francois: We do web standards. I didn't mention it, but it's from the name. Standards that you find in your web browsers. But not only that, there are a number of other, uh, standards that got developed at W3C including, for example, XML. Data related standards. W3C as an organization is a consortium. [00:01:43] Francois: The, the C stands for consortium. Legally speaking, it's a, it's a 501c3 meaning in, so it's a US based, uh, legal entity not for profit. And the, the little three is important because it means it's public interest. That means we are a consortium, that means we have members, but at the same time, the goal, the mission is to the public. [00:02:05] Francois: So we're not only just, you know, doing what our members want. We are also making sure that what our members want is aligned with what end users in the end, need. and the W3C has a small team. And so I'm part of this, uh, of this team worldwide. Uh, 45 to 55 people, depending on how you count, mostly technical people and some, uh, admin, uh, as well, overseeing the, uh, the work, that we do, uh, at the W3C. Funding through membership fees [00:02:39] Jeremy: So you mentioned there's 45 to 55 people. How is this funded? Is this from governments or commercial companies? [00:02:47] Francois: The main source comes from membership fees. So the W3C has a, so members, uh, roughly 350 members, uh, at the W3C. And, in order to become a member, an organization needs to pay, uh, an annual membership fee. That's pretty common among, uh, standardization, uh, organizations. [00:03:07] Francois: And, we only have, uh, I guess three levels of membership, fees. Uh, well, you may find, uh, additional small levels, but three main ones. the goal is to make sure that, A big player will, not a big player or large company, will not have more rights than, uh, anything, anyone else. So we try to make sure that a member has the, you know, all members have equal, right? [00:03:30] Francois: if it's not perfect, but, uh, uh, that's how things are, are are set. So that's the main source of income for the W3C. And then we try to diversify just a little bit to get, uh, for example, we go to governments. We may go to governments in the u EU. We may, uh, take some, uh, grant for EU research projects that allow us, you know, to, study, explore topics. [00:03:54] Francois: Uh, in the US there, there used to be some, uh, some funding from coming from the government as well. So that, that's, uh, also, uh, a source. But the main one is, uh, membership fees. Relations to TC39, IETF, and WHATWG [00:04:04] Jeremy: And you mentioned that a lot of the W3C'S work is related to web standards. There's other groups like TC 39, which works on the JavaScript spec and the IETF, which I believe worked, with your group on WebRTC, I wonder if you could explain W3C'S connection to other groups like that. [00:04:28] Francois: sure. we try to collaborate with a, a number of, uh, standard other standardization organizations. So in general, everything goes well because you, you have, a clear separation of concerns. So you mentioned TC 39. Indeed. they are the ones who standardize, JavaScript. Proper name of JavaScript is the EcmaScript. [00:04:47] Francois: So that's tc. TC 39 is the technical committee at ecma. and so we have indeed interactions with them because their work directly impact the JavaScript that you're going to find in your, uh, run in your, in your web browser. And we develop a number of JavaScript APIs, uh, actually in W3C. [00:05:05] Francois: So we need to make sure that, the way we develop, uh, you know, these APIs align with the, the language itself. with IETF, the, the, the boundary is, uh, uh, is clear as well. It's a protocol and protocol for our network protocols for our, the IETF and application level. For W3C, that's usually how the distinction is made. [00:05:28] Francois: The boundaries are always a bit fuzzy, but that's how things work. And usually, uh, things work pretty well. Uh, there's also the WHATWG, uh, and the WHATWG is more the, the, the history was more complicated because, uh, t of a fork of the, uh, HTML specification, uh, at the time when it was developed by W3C, a long time ago. [00:05:49] Francois: And there was been some, uh, Well disagreement on the way things should have been done, and the WHATWG took over got created, took, took this the HTML spec and did it a different way. Went in another, another direction, and that other, other direction actually ended up being the direction. [00:06:06] Francois: So, that's a success, uh, from there. And so, W3C no longer works, no longer owns the, uh, HTML spec and the WHATWG has, uh, taken, uh, taken up a number of, uh, of different, core specifications for the web. Uh, doing a lot of work on the, uh, on interopoerability and making sure that, uh, the algorithm specified by the spec, were correct, which, which was something that historically we haven't been very good at at W3C. [00:06:35] Francois: And the way they've been working as a, has a lot of influence on the way we develop now, uh, the APIs, uh, from a W3C perspective. [00:06:44] Jeremy: So, just to make sure I understand correctly, you have TC 39, which is focused on the JavaScript or ECMAScript language itself, and you have APIs that are going to use JavaScript and interact with JavaScript. So you need to coordinate there. The, the have the specification for HTML. then the IATF, they are, I'm not sure if the right term would be, they, they would be one level lower perhaps, than the W3C. [00:07:17] Francois: That's how you, you can formulate it. Yes. The, the one layer, one layer layer in the ISO network in the ISO stack at the network level. How WebRTC spans the IETF and W3C [00:07:30] Jeremy: And so in that case, one place I've heard it mentioned is that webRTC, to, to use it, there is an IETF specification, and then perhaps there's a W3C recommendation and [00:07:43] Francois: Yes. so when we created the webRTC working group, that was in 2011, I think, it was created with a dual head. There was one RTC web, group that got created at IETF and a webRTC group that got created at W3C. And that was done on purpose. Of course, the goal was not to compete on the, on the solution, but actually to, have the two sides of the, uh, solution, be developed in parallel, the API, uh, the application front and the network front. [00:08:15] Francois: And there was a, and there's still a lot of overlap in, uh, participation between both groups, and that's what keep things successful. In the end. It's not, uh, you know, process or organization to organization, uh, relationships, coordination at the organization level. It's really the fact that you have participants that are essentially the same, on both sides of the equation. [00:08:36] Francois: That helps, uh, move things forward. Now, webRTC is, uh, is more complex than just one group at IETF. I mean, web, webRTC is a very complex set of, uh, of technologies, stack of technologies. So when you, when you. Pull a little, uh, protocol from IETFs. Suddenly you have the whole IETF that comes with you with it. [00:08:56] Francois: So you, it's the, you have the feeling that webRTC needs all of the, uh, internet protocols that got, uh, created to work Recommendations [00:09:04] Jeremy: And I think probably a lot of web developers, they may hear words like specification or standard, but I believe the, the official term, at least at the W3C, is this recommendation. And so I wonder if you can explain what that means. [00:09:24] Francois: Well. It means it means standard in the end. and that came from industry. That comes from a time where. As many standardization organizations. W3C was created not to be a standardization organization. It was felt that standard was not the right term because we were not a standardization organization. [00:09:45] Francois: So recommend IETF has the same thing. They call it RFC, request for comment, which, you know, stands for nothing in, and yet it's a standard. So W3C was created with the same kind of, uh thing. We needed some other terminology and we call that recommendation. But in the end, that's standard. It's really, uh, how you should see it. [00:10:08] Francois: And one thing I didn't mention when I, uh, introduced the W3C is there are two types of standards in the end, two main categories. There are, the de jure standards and defacto standards, two families. The de jure standards are the ones that are imposed by some kind of regulation. so it's really usually a standard you see imposed by governments, for example. [00:10:29] Francois: So when you look at your electric plug at home, there's some regulation there that says, this plug needs to have these properties. And that's a standard that gets imposed. It's a de jure standard. and then there are defacto standards which are really, uh, specifications that are out there and people agree to use it to implement it. [00:10:49] Francois: And by virtue of being used and implemented and used by everyone, they become standards. the, W3C really is in the, uh, second part. It's a defacto standard. IETF is the same thing. some of our standards are used in, uh, are referenced in regulations now, but, just a, a minority of them, most of them are defacto standards. [00:11:10] Francois: and that's important because that's in the end, it doesn't matter what the specific specification says, even though it's a bit confusing. What matters is that the, what the specifications says matches what implementations actually implement, and that these implementations are used, and are used interoperably across, you know, across browsers, for example, or across, uh, implementations, across users, across usages. [00:11:36] Francois: So, uh, standardization is a, is a lengthy process. The recommendation is the final stage in that, lengthy process. More and more we don't really reach recommendation anymore. If you look at, uh, at groups, uh, because we have another path, let's say we kind of, uh, we can stop at candidate recommendation, which is in theoretically a step before that. [00:12:02] Francois: But then you, you can stay there and, uh, stay there forever and publish new candidate recommendations. Um, uh, later on. What matters again is that, you know, you get this, virtuous feedback loop, uh, with implementers, and usage. [00:12:18] Jeremy: So if the candidate recommendation ends up being implemented by all the browsers, what's ends up being the distinction between a candidate and one that's a normal recommendation. [00:12:31] Francois: So, today it's mostly a process thing. Some groups actually decide to go to rec Some groups decide to stay at candidate rec and there's no formal difference between the, the two. we've made sure we've adopted, adjusted the process so that the important bits that, applied at the recommendation level now apply at the candidate rec level. Royalty free patent access [00:13:00] Francois: And by important things, I mean the patent commitments typically, uh, the patent policy fully applies at the candidate recommendation level so that you get your, protection, the royalty free patent protection that we, we were aiming at. [00:13:14] Francois: Some people do not care, you know, but most of the world still works with, uh, with patents, uh, for good, uh, or bad reasons. But, uh, uh, that's how things work. So we need to make, we're trying to make sure that we, we secure the right set of, um, of patent commitments from the right set of stakeholders. [00:13:35] Jeremy: Oh, so when someone implements a W3C recommendation or a candidate recommendation, the patent holders related to that recommendation, they basically agree to allow royalty-free use of that patent. [00:13:54] Francois: They do the one that were involved in the working group, of course, I mean, we can't say anything about the companies out there that may have patents and uh, are not part of this standardization process. So there's always, It's a remaining risk. but part of the goal when we create a working group is to make sure that, people understand the scope. [00:14:17] Francois: Lawyers look into it, and the, the legal teams that exist at the all the large companies, basically gave a green light saying, yeah, we, we we're pretty confident that we, we know where the patterns are on this particular, this particular area. And we are fine also, uh, letting go of the, the patterns we own ourselves. Implementations are built in parallel with standardization [00:14:39] Jeremy: And I think you had mentioned. What ends up being the most important is that the browser creators implement these recommendations. So it sounds like maybe the distinction between candidate recommendation and recommendation almost doesn't matter as long as you get the end result you want. [00:15:03] Francois: So, I mean, people will have different opinions, uh, in the, in standardization circles. And I mentioned also W3C is working on other kind of, uh, standards. So, uh, in some other areas, the nuance may be more important when we, but when, when you look at specification, that's target, web browsers. we've switched from a model where, specs were developed first and then implemented to a model where specs and implementing implementations are being, worked in parallel. [00:15:35] Francois: This actually relates to the evolution I was mentioning with the WHATWG taking over the HTML and, uh, focusing on the interoperability issues because the starting point was, yeah, we have an HTML 4.01 spec, uh, but it's not interoperable because it, it's not specified, are number of areas that are gray areas, you can implement them differently. [00:15:59] Francois: And so there are interoperable issues. Back to candidate rec actually, the, the, the, the stage was created, if I remember correctly. uh, if I'm, if I'm not wrong, the stage was created following the, uh, IE problem. In the CSS working group, IE6, uh, shipped with some, version of a CSS that was in the, as specified, you know, the spec was saying, you know, do that for the CSS box model. [00:16:27] Francois: And the IE6 was following that. And then the group decided to change, the box model and suddenly IE6 was no longer compliant. And that created a, a huge mess on the, in the history of, uh, of the web in a way. And so the, we, the, the, the, the candidate recommendation sta uh, stage was introduced following that to try to catch this kind of problems. [00:16:52] Francois: But nowadays, again, we, we switch to another model where it's more live. and so we, you, you'll find a number of specs that are not even at candidate rec level. They are at the, what we call a working draft, and they, they are being implemented, and if all goes well, the standardization process follows the implementation, and then you end up in a situation where you have your candidate rec when the, uh, spec ships. [00:17:18] Francois: a recent example would be a web GPU, for example. It, uh, it has shipped in, uh, in, in Chrome shortly before it transition to a candidate rec. But the, the, the spec was already stable. and now it's shipping uh, in, uh, in different browsers, uh, uh, safari, uh, and uh, and uh, and uh, Firefox. And so that's, uh, and that's a good example of something that follows, uh, things, uh, along pretty well. But then you have other specs such as, uh, in the media space, uh, request video frame back, uh, frame, call back, uh, requestVideoFrameCallback() is a short API that allows you to get, you know, a call back whenever the, the browser renders a video frame, essentially. [00:18:01] Francois: And that spec is implemented across browsers. But from a W3C specific, perspective, it does not even exist. It's not on the standardization track. It's still being incubated in what we call a community group, which is, you know, some something that, uh, usually exists before. we move to the, the standardization process. [00:18:21] Francois: So there, there are examples of things where some things fell through the cracks. All the standardization process, uh, is either too early or too late and things that are in spec are not exactly what what got implemented or implementations are too early in the process. We we're doing a better job, at, Not falling into a trap where someone ships, uh, you know, an implementation and then suddenly everything is frozen. You can no longer, change it because it's too late, it shipped. we've tried, different, path there. Um, mentioned CSS, the, there was this kind of vendor prefixed, uh, properties that used to be, uh, the way, uh, browsers were deploying new features without, you know, taking the final name. [00:19:06] Francois: We are trying also to move away from it because same thing. Then in the end, you end up with, uh, applications that have, uh, to duplicate all the properties, the CSS properties in the style sheets with, uh, the vendor prefixes and nuances in the, in what it does in, in the end. [00:19:23] Jeremy: Yeah, I, I think, is that in CSS where you'll see --mozilla or things like that? Why requestVideoFrameCallback doesn't have a formal specification [00:19:30] Jeremy: The example of the request video frame callback. I, I wonder if you have an opinion or, or, or know why that ended up the way it did, where the browsers all implemented it, even though it was still in the incubation stage. [00:19:49] Francois: On this one, I don't have a particular, uh, insights on whether there was a, you know, a strong reason to implement it,without doing the standardization work. [00:19:58] Francois: I mean, there are, it's not, uh, an IPR (Intellectual Property Rights) issue. It's not, uh, something that, uh, I don't think the, the, the spec triggers, uh, you know, problems that, uh, would be controversial or whatever. [00:20:10] Francois: Uh, so it's just a matter of, uh, there was no one's priority, and in the end, you end up with a, everyone's happy. it's, it has shipped. And so now doing the spec work is a bit,why spend time on something that's already shipped and so on, but the, it may still come back at some point with try to, you know, improve the situation. [00:20:26] Jeremy: Yeah, that's, that's interesting. It's a little counterintuitive because it sounds like you have the, the working group and it, it sounds like perhaps the companies or organizations involved, they maybe agreed on how it should work, and maybe that agreement almost made it so that they felt like they didn't need to move forward with the specification because they came to consensus even before going through that. [00:20:53] Francois: In this particular case, it's probably because it's really, again, it's a small, spec. It's just one function call, you know? I mean, they will definitely want a working group, uh, for larger specifications. by the way, actually now I know re request video frame call back. It's because the, the, the final goal now that it's, uh, shipped, is to merge it into, uh, HTML, uh, the HTML spec. [00:21:17] Francois: So there's a, there's an ongoing issue on the, the WHATWG side to integrate request video frame callback. And it's taking some time but see, it's, it's being, it, it caught up and, uh, someone is doing the, the work to, to do it. I had forgotten about this one. Um, [00:21:33] Jeremy: Tension from specification review (horizontal review) [00:21:33] Francois: so with larger specifications, organizations will want this kind of IPR regime they will want commit commitments from, uh, others, on the scope, on the process, on everything. So they will want, uh, a larger, a, a more formal setting, because that's part of how you ensure that things, uh, will get done properly. [00:21:53] Francois: I didn't mention it, but, uh, something we're really, uh, Pushy on, uh, W3C I mentioned we have principles, we have priorities, and we have, uh, specific several, uh, properties at W3C. And one of them is that we we're very strong on horizontal reviews of our specs. We really want them to be reviewed from an accessibility perspective, from an internationalization perspective, from a privacy and security, uh, perspective, and, and, and a technical architecture perspective as well. [00:22:23] Francois: And that's, these reviews are part of the formal process. So you, all specs need to undergo these reviews. And from time to time, that creates tension. Uh, from time to time. It just works, you know. Goes without problem. a recurring issue is that, privacy and security are hard. I mean, it's not an easy problem, something that can be, uh, solved, uh, easily. [00:22:48] Francois: Uh, so there's a, an ongoing tension and no easy way to resolve it, but there's an ongoing tension between, specifying powerful APIs and preserving privacy without meaning, not exposing too much information to applications in the media space. You can think of the media capabilities, API. So the media space is a complicated space. [00:23:13] Francois: Space because of codecs. codecs are typically not relative free. and so browsers decide which codecs they're going to support, which audio and video codecs they, they're going to support and doing that, that creates additional fragmentation, not in the sense that they're not interoperable, but in the sense that applications need to choose which connect they're going to ship to stream to the end user. [00:23:39] Francois: And, uh, it's all the more complicated that some codecs are going to be hardware supported. So you will have a hardware decoder in your, in your, in your laptop or smartphone. And so that's going to be efficient to decode some, uh, some stream, whereas some code are not, are going to be software, based, supported. [00:23:56] Francois: Uh, and that may consume a lot of CPU and a lot of power and a lot of energy in the end. So you, you want to avoid that if you can, uh, select another thing. Even more complex than, codecs have different profiles, uh, lower end profiles higher end profiles with different capabilities, different features, uh, depending on whether you're going to use this or that color space, for example, this or that resolution, whatever. [00:24:22] Francois: And so you want to surface that to web applications because otherwise, they can't. Select, they can't choose, the right codec and the right, stream that they're going to send to the, uh, client devices. And so they're not going to provide an efficient user experience first, and even a sustainable one in terms of energy because they, they're going to waste energy if they don't send the right stream. [00:24:45] Francois: So you want to surface that to application. That's what the media, media capabilities, APIs, provides. Privacy concerns [00:24:51] Francois: Uh, but at the same time, if you expose that information, you end up with ways to fingerprint the end user's device. And that in turn is often used to track users across, across sites, which is exactly what we don't want to have, uh, for privacy reasons, for obvious privacy reasons. [00:25:09] Francois: So you have to balance that and find ways to, uh, you know, to expose. Capabilities without, without necessarily exposing them too much. Uh, [00:25:21] Jeremy: Can you give an example of how some of those discussions went? Like within the working group? Who are the companies or who are the organizations that are arguing for We shouldn't have this capability because of the privacy concerns, or [00:25:40] Francois: In a way all of the companies, have a vision of, uh, of privacy. I mean, the, you will have a hard time finding, you know, members saying, I don't care about privacy. I just want the feature. Uh, they all have privacy in mind, but they may have a different approach to privacy. [00:25:57] Francois: so if you take, uh, let's say, uh, apple and Google would be the, the, I guess the perfect examples in that, uh, in that space, uh, Google will have a, an approach that is more open-ended thing. The, the user agents has this, uh, should check what the, the, uh, given site is doing. And then if it goes beyond, you know, some kind of threshold, they're going to say, well, okay, well, we'll stop exposing data to that, to that, uh, to that site. [00:26:25] Francois: So that application. So monitor and react in a way. apple has a more, uh, you know, has a stricter view on, uh, on privacy, let's say. And they will say, no, we, the, the, the feature must not exist in the first place. Or, but that's, I mean, I guess, um, it's not always that extreme. And, uh, from time to time it's the opposite. [00:26:45] Francois: You will have, uh, you know, apple arguing in one way, uh, which is more open-ended than the, uh, than, uh, than Google, for example. And they are not the only ones. So in working groups, uh, you will find the, usually the implementers. Uh, so when we talk about APIs that get implemented in browsers, you want the core browsers to be involved. [00:27:04] Francois: Uh, otherwise it's usually not a good sign for, uh, the success of the, uh, of the technology. So in practice, that means Apple, uh, Microsoft, Mozilla which one did I forget? [00:27:15] Jeremy: Google. [00:27:16] Francois: I forgot Google. Of course. Thank you. that's, uh, that the, the core, uh, list of participants you want to have in any, uh, group that develops web standards targeted at web browsers. Who participates in working groups and how much power do they have? [00:27:28] Francois: And then on top of that, you want, organizations and people who are directly going to use it, either because they, well the content providers. So in media, for example, if you look at the media working group, you'll see, uh, so browser vendors, the ones I mentioned, uh, content providers such as the BBC or Netflix. [00:27:46] Francois: Chip set vendors would, uh, would be there as well. Intel, uh, Nvidia again, because you know, there's a hardware decoding in there and encoding. So media is, touches on, on, uh, on hardware, uh, device manufacturer in general. You may, uh, I think, uh, I think Sony is involved in the, in the media working group, for example. [00:28:04] Francois: and these companies are usually less active in the spec development. It depends on the groups, but they're usually less active because the ones developing the specs are usually the browser again, because as I mentioned, we develop the specs in parallel to browsers implementing it. So they have the. [00:28:21] Francois: The feedback on how to formulate the, the algorithms. and so that's this collection of people who are going to discuss first within themselves. W3C pushes for consensual dis decisions. So we hardly take any votes in the working groups, but from time to time, that's not enough. [00:28:41] Francois: And there may be disagreements, but let's say there's agreement in the group, uh, when the spec matches. horizontal review groups will look at the specs. So these are groups I mentioned, accessibility one, uh, privacy, internationalization. And these groups, usually the participants are, it depends. [00:29:00] Francois: It can be anything. It can be, uh, the same companies. It can be, but usually different people from the same companies. But it the, maybe organizations with a that come from very, a very different angle. And that's a good thing because that means the, you know, you enlarge the, the perspectives on your, uh, on the, on the technology. [00:29:19] Francois: and you, that's when you have a discussion between groups, that takes place. And from time to time it goes well from time to time. Again, it can trigger issues that are hard to solve. and the W3C has a, an escalation process in case, uh, you know, in case things degenerate. Uh, starting with, uh, the notion of formal objection. [00:29:42] Jeremy: It makes sense that you would have the, the browser. Vendors and you have all the different companies that would use that browser. All the different horizontal groups like you mentioned, the internationalization, accessibility. I would imagine that you were talking about consensus and there are certain groups or certain companies that maybe have more say or more sway. [00:30:09] Jeremy: For example, if you're a browser, manufacturer, your Google. I'm kind of curious how that works out within the working group. [00:30:15] Francois: Yes, it's, I guess I would be lying if I were saying that, uh, you know, all companies are strictly equal in a, in a, in a group. they are from a process perspective, I mentioned, you know, different membership fees with were design, special specific ethos so that no one could say, I'm, I'm putting in a lot of money, so you, you need to re you need to respect me, uh, and you need to follow what I, what I want to, what I want to do. [00:30:41] Francois: at the same time, if you take a company like, uh, like Google for example, they send, hundreds of engineers to do standardization work. That's absolutely fantastic because that means work progresses and it's, uh, extremely smart people. So that's, uh, that's really a pleasure to work with, uh, with these, uh, people. [00:30:58] Francois: But you need to take a step back and say, well, the problem is. Defacto that gives them more power just by virtue of, uh, injecting more resources into it. So having always someone who can respond to an issue, having always someone, uh, editing a spec defacto that give them more, uh, um, more say on the, on the directions that, get forward. [00:31:22] Francois: And on top of that, of course, they have the, uh, I guess not surprisingly, the, the browser that is, uh, used the most, currently, on the market so there's a little bit of a, the, the, we, we, we, we try very hard to make sure that, uh, things are balanced. it's not a perfect world. [00:31:38] Francois: the the role of the team. I mean, I didn't talk about the role of the team, but part of it is to make sure that. Again, all perspectives are represented and that there's not, such a, such big imbalance that, uh, that something is wrong and that we really need to look into it. so making sure that anyone, if they have something to say, make making sure that they are heard by the rest of the group and not dismissed. [00:32:05] Francois: That usually goes well. There's no problem with that. And again, the escalation process I mentioned here doesn't make any, uh, it doesn't make any difference between, uh, a small player, a large player, a big player, and we have small companies raising formal objections against some of our aspects that happens, uh, all large ones. [00:32:24] Francois: But, uh, that happens too. There's no magical solution, I guess you can tell it by the way. I, uh, I don't know how to formulate the, the process more. It's a human process, and that's very important that it remains a human process as well. [00:32:41] Jeremy: I suppose the role of, of staff and someone in your position, for example, is to try and ensure that these different groups are, are heard and it isn't just one group taking control of it. [00:32:55] Francois: That's part of the role, again, is to make sure that, uh, the, the process is followed. So the, I, I mean, I don't want to give the impression that the process controls everything in the groups. I mean, the, the, the groups are bound by the process, but the process is there to catch problems when they arise. [00:33:14] Francois: most of the time there are no problems. It's just, you know, again, participants talking to each other, talking with the rest of the community. Most of the work happens in public nowadays, in any case. So the groups work in public essentially through asynchronous, uh, discussions on GitHub repositories. [00:33:32] Francois: There are contributions from, you know, non group participants and everything goes well. And so the process doesn't kick in. You just never say, eh, no, you didn't respect the process there. You, you closed the issue. You shouldn't have a, it's pretty rare that you have to do that. Uh, things just proceed naturally because they all, everyone understands where they are, why, what they're doing, and why they're doing it. [00:33:55] Francois: we still have a role, I guess in the, in the sense that from time to time that doesn't work and you have to intervene and you have to make sure that,the, uh, exception is caught and, uh, and processed, uh, in the right way. Discussions are public on github [00:34:10] Jeremy: And you said this process is asynchronous in public, so it sounds like someone, I, I mean, is this in GitHub issues or how, how would somebody go and, and see what the results of [00:34:22] Francois: Yes, there, there are basically a gazillion of, uh, GitHub repositories under the, uh, W3C, uh, organization on GitHub. Most groups are using GitHub. I mean, there's no, it's not mandatory. We don't manage any, uh, any tooling. But the factors that most, we, we've been transitioning to GitHub, uh, for a number of years already. [00:34:45] Francois: Uh, so that's where the work most of the work happens, through issues, through pool requests. Uh, that's where. people can go and raise issues against specifications. Uh, we usually, uh, also some from time to time get feedback from developers and countering, uh, a bug in a particular implementations, which we try to gently redirect to, uh, the actual bug trackers because we're not responsible for the respons implementations of the specs unless the spec is not clear. [00:35:14] Francois: We are responsible for the spec itself, making sure that the spec is clear and that implementers well, understand how they should implement something. Why the W3C doesn't specify a video or audio codec [00:35:25] Jeremy: I can see how people would make that mistake because they, they see it's the feature, but that's not the responsibility of the, the W3C to implement any of the specifications. Something you had mentioned there's the issue of intellectual property rights and how when you have a recommendation, you require the different organizations involved to make their patents available to use freely. [00:35:54] Jeremy: I wonder why there was never any kind of, recommendation for audio or video codecs in browsers since you have certain ones that are considered royalty free. But, I believe that's never been specified. [00:36:11] Francois: At W3C you mean? Yes. we, we've tried, I mean, it's not for lack of trying. Um, uh, we've had a number of discussions with, uh, various stakeholders saying, Hey, we, we really need, an audio or video code for our, for the web. the, uh, png PNG is an example of a, um, an image format which got standardized at W3C and it got standardized at W3C similar reasons. There had to be a royalty free image format for the web, and there was none at the time. of course, nowadays, uh, jpeg, uh, and gif or gif, whatever you call it, are well, you know, no problem with them. But, uh, um, that at the time P PNG was really, uh, meant to address this issue and it worked for PNG for audio and video. [00:37:01] Francois: We haven't managed to secure, commitments by stakeholders. So willingness to do it, so it's not, it's not lack of willingness. We would've loved to, uh, get, uh, a royalty free, uh, audio codec, a royalty free video codec again, audio and video code are extremely complicated because of this. [00:37:20] Francois: not only because of patterns, but also because of the entire business ecosystem that exists around them for good reasons. You, in order for a, a codec to be supported, deployed, effective, it really needs, uh, it needs to mature a lot. It needs to, be, uh, added to at a hardware level, to a number of devices, capturing devices, but also, um, uh, uh, of course players. [00:37:46] Francois: And that takes a hell of a lot of time and that's why you also enter a number of business considerations with business contracts between entities. so I'm personally, on a personal level, I'm, I'm pleased to see, for example, the Alliance for Open Media working on, uh, uh, AV1, uh, which is. At least they, uh, they wanted to be royalty free and they've been adopting actually the W3C patent policy to do this work. [00:38:11] Francois: So, uh, we're pleased to see that, you know, they've been adopting the same process and same thing. AV1 is not yet at the same, support stage, as other, codecs, in the world Yeah, I mean in devices. There's an open question as what, what are we going to do, uh, in the future uh, with that, it's, it's, it's doubtful that, uh, the W3C will be able to work on a, on a royalty free audio, codec or royalty free video codec itself because, uh, probably it's too late now in any case. [00:38:43] Francois: but It's one of these angles in the, in the web platform where we wish we had the, uh, the technology available for, for free. And, uh, it's not exactly, uh, how things work in practice.I mean, the way codecs are developed remains really patent oriented. [00:38:57] Francois: and you will find more codecs being developed. and that's where geopolitics can even enter the, the, uh, the play. Because, uh, if you go to China, you will find new codecs emerging, uh, that get developed within China also, because, the other codecs come mostly from the US so it's a bit of a problem and so on. [00:39:17] Francois: I'm not going to enter details and uh, I would probably say stupid things in any case. Uh, but that, uh, so we continue to see, uh, emerging codecs that are not royalty free, and it's probably going to remain the case for a number of years. unfortunately, unfortunately, from a W3C perspective and my perspective of course. [00:39:38] Jeremy: There's always these new, formats coming out and the, rate at which they get supported in the browser, even on a per browser basis is, is very, there can be a long time between, for example, WebP being released and a browser supporting it. So, seems like maybe we're gonna be in that situation for a while where the codecs will come out and maybe the browsers will support them. Maybe they won't, but the, the timeline is very uncertain. Digital Rights Management (DRM) and Media Source Extensions [00:40:08] Jeremy: Something you had, mentioned, maybe this was in your, email to me earlier, but you had mentioned that some of these specifications, there's, there's business considerations like with, digital rights management and, media source extensions. I wonder if you could talk a little bit about maybe what media source extensions is and encrypted media extensions and, and what the, the considerations or challenges are there. [00:40:33] Francois: I'm going to go very, very quickly over the history of a, video and audio support on the web. Initially it was supported through plugins. you are maybe too young to, remember that. But, uh, we had extensions, added to, uh, a realplayer. [00:40:46] Francois: This kind of things flash as well, uh, supporting, uh, uh, videos, in web pages, but it was not provided by the web browsers themselves. Uh, then HTML5 changed the, the situation. Adding these new tags, audio and video, but that these tags on this, by default, support, uh, you give them a resources, a resource, like an image as it's an audio or a video file. [00:41:10] Francois: They're going to download this, uh, uh, video file or audio file, and they're going to play it. That works well. But as soon as you want to do any kind of real streaming, files are too large and to stream, to, to get, you know, to get just a single fetch on, uh, on them. So you really want to stream them chunk by chunk, and you want to adapt the resolution at which you send the stream based on real time conditions of the user's network. [00:41:37] Francois: If there's plenty of bandwidth you want to send the user, the highest possible resolution. If there's a, some kind of hiccup temporary in the, in the network, you really want to lower the resolution, and that's called adaptive streaming. And to get adaptive streaming on the web, well, there are a number of protocols that exist. [00:41:54] Francois: Same thing. Some many of them are proprietary and actually they remain proprietary, uh, to some extent. and, uh, some of them are over http and they are the ones that are primarily used in, uh, in web contexts. So DASH comes to mind, DASH for Dynamic Adaptive streaming over http. HLS is another one. Uh, initially developed by Apple, I believe, and it's, uh, HTTP live streaming probably. Exactly. And, so there are different protocols that you can, uh, you can use. Uh, so the goal was not to standardize these protocols because again, there were some proprietary aspects to them. And, uh, same thing as with codecs. [00:42:32] Francois: There was no, well, at least people wanted to have the, uh, flexibility to tweak parameters, adaptive streaming parameters the way they wanted for different scenarios. You may want to tweak the parameters differently. So they, they needed to be more flexibility on top of protocols not being truly available for use directly and for implementation directly in browsers. [00:42:53] Francois: It was also about providing applications with, uh, the flexibility they would need to tweak parameters. So media source extensions comes into play for exactly that. Media source extensions is really about you. The application fetches chunks of its audio and video stream the way it wants, and with the parameters it wants, and it adjusts whatever it wants. [00:43:15] Francois: And then it feeds that into the, uh, video or audio tag. and the browser takes care of the rest. So it's really about, doing, you know, the adaptive streaming. let applications do it, and then, uh, let the user agent, uh, the browser takes, take care of the rendering itself. That's media source extensions. [00:43:32] Francois: Initially it was pushed by, uh, Netflix. They were not the only ones of course, but there, there was a, a ma, a major, uh, proponent of this, uh, technical solution, because they wanted, uh, they, uh, they were, expanding all over the world, uh, with, uh, plenty of native, applications on all sorts of, uh, of, uh, devices. [00:43:52] Francois: And they wanted to have a way to stream content on the web as well. both for both, I guess, to expand to, um, a new, um, ecosystem, the web, uh, providing new opportunities, let's say. But at the same time also to have a fallback, in case they, because for native support on different platforms, they sometimes had to enter business agreements with, uh, you know, the hardware manufacturers, the whatever, the, uh, service provider or whatever. [00:44:19] Francois: and so that was a way to have a full back. That kind of work is more open, in case, uh, things take some time and so on. So, and they probably had other reasons. I mean, I'm not, I can't speak on behalf of Netflix, uh, on others, but they were not the only ones of course, uh, supporting this, uh, me, uh, media source extension, uh, uh, specification. [00:44:42] Francois: and that went kind of, well, I think it was creating 2011. I mean, the, the work started in 2011 and the recommendation was published in 2016, which is not too bad from a standardization perspective. It means only five years, you know, it's a very short amount of time. Encrypted Media Extensions [00:44:59] Francois: At the same time, and in parallel and complement to the media source extension specifications, uh, there was work on the encrypted media extensions, and here it was pushed by the same proponent in a way because they wanted to get premium content on the web. [00:45:14] Francois: And by premium content, you think of movies and, uh. These kind of beasts. And the problem with the, I guess the basic issue with, uh, digital asset such as movies, is that they cost hundreds of millions to produce. I mean, some cost less of course. And yet it's super easy to copy them if you have a access to the digital, uh, file. [00:45:35] Francois: You just copy and, uh, and that's it. Piracy uh, is super easy, uh, to achieve. It's illegal of course, but it's super easy to do. And so that's where the different legislations come into play with digital right management. Then the fact is most countries allow system that, can encrypt content and, uh, through what we call DRM systems. [00:45:59] Francois: so content providers, uh, the, the ones that have movies, so the studios here more, more and more, and Netflix is one, uh, one of the studios nowadays. Um, but not only, not only them all major studios will, uh, would, uh, push for, wanted to have something that would allow them to stream encrypted content, encrypted audio and video, uh, mostly video, to, uh, to web applications so that, uh, you. [00:46:25] Francois: Provide the movies, otherwise, they, they are just basically saying, and sorry, but, uh, this premium content will never make it to the web because there's no way we're gonna, uh, send it in clear, to, uh, to the end user. So Encrypting media extensions is, uh, is an API that allows to interface with, uh, what's called the content decryption module, CDM, uh, which itself interacts with, uh, the DR DRM systems that, uh, the browser may, may or may not support. [00:46:52] Francois: And so it provides a way for an application to receive encrypted content, pass it over get the, the, the right keys, the right license keys from a whatever system actually. Pass that logic over to the, and to the user agent, which passes, passes it over to, uh, the CDM system, which is kind of black box in, uh, that does its magic to get the right, uh, decryption key and then the, and to decrypt the content that can be rendered. [00:47:21] Francois: The encrypted media extensions triggered a, a hell of a lot of, uh, controversy. because it's DRM and DRM systems, uh, many people, uh, uh, things should be banned, uh, especially on the web because the, the premise of the web is that the, the user has trusts, a user agent. The, the web browser is called the user agent in all our, all our specifications. [00:47:44] Francois: And that's, uh, that's the trust relationship. And then they interact with a, a content provider. And so whatever they do with the content is their, I guess, actually their problem. And DRM introduces a third party, which is, uh, there's, uh, the, the end user no longer has the control on the content. [00:48:03] Francois: It has to rely on something else that, Restricts what it can achieve with the content. So it's, uh, it's not only a trust relationship with its, uh, user agents, it's also with, uh, with something else, which is the content provider, uh, in the end, the one that has the, uh, the license where provides the license. [00:48:22] Francois: And so that's, that triggers, uh, a hell of a lot of, uh, of discussions in the W3C degenerated, uh, uh, into, uh, formal objections being raised against the specification. and that escalated to, to the, I mean, at all leverage it. It's, it's the, the story in, uh, W3C that, um, really, uh, divided the membership into, opposed camps in a way, if you, that's was not only year, it was not really 50 50 in the sense that not just a huge fights, but the, that's, that triggered a hell of a lot of discussions and a lot of, a lot of, uh, of formal objections at the time. [00:49:00] Francois: Uh, we were still, From a governance perspective, interestingly, um, the W3C used to be a dictatorship. It's not how you should formulate it, of course, and I hope it's not going to be public, this podcast. Uh, but the, uh, it was a benevolent dictatorship. You could see it this way in the sense that, uh, the whole process escalated to one single person was, Tim Burners Lee, who had the final say, on when, when none of the other layers, had managed to catch and to resolve, a conflict. [00:49:32] Francois: Uh, that has hardly ever happened in, uh, the history of the W3C, but that happened to the two for EME, for encrypted media extensions. It had to go to the, uh, director level who, uh, after due consideration, uh, decided to, allow the EME to proceed. and that's why we have a, an EME, uh, uh, standard right now, but still re it remains something on the side. [00:49:56] Francois: EME we're still, uh, it's still in the scope of the media working group, for example. but the scope, if you look at the charter of the working group, we try to scope the, the, the, the, the updates we can make to the specification, uh, to make sure that we don't reopen, reopen, uh, a can of worms, because, well, it's really a, a topic that triggers friction for good and bad reasons again. [00:50:20] Jeremy: And when you talk about the media source extensions, that is the ability to write custom code to stream video in whatever way you want. You mentioned, the MPEG-DASH and http live streaming. So in that case, would that be the developer gets to write that code in JavaScript that's executed by the browser? [00:50:43] Francois: Yep, that's, uh, that would be it. and then typically, I guess the approach nowadays is more and more to develop low level APIs into W3C or web in, in general, I guess. And to let, uh. Libraries emerge that are going to make lives of a, a developer, uh, easier. So for MPEG DASH, we have the DASH.js, which does a fantastic job at, uh, at implementing the complexity of, uh, of adaptive streaming. [00:51:13] Francois: And you just, you just hook it into your, your workflow. And that's, uh, and that's it. Encrypted Media Extensions are closed source [00:51:20] Jeremy: And with the encrypted media extensions I'm trying to picture how those work and how they work differently. [00:51:28] Francois: Well, it's because the, the, the, the key architecture is that the, the stream that you, the stream that you may assemble with a media source extensions, for example. 'cause typically they, they're used in collaboration. When you hook the, hook it into the video tag, you also. Call EME and actually the stream goes to EME. [00:51:49] Francois: And when it goes to EME, actually the user agent hands the encrypted stream. You're still encrypted at this time. Uh, encrypted, uh, stream goes to the CDM content decryption module, and that's a black box well, it has some black, black, uh, black box logic. So it's not, uh, even if you look at the chromium source code, for example, you won't see the implementation of the CDM because it's a, it's a black box, so it's not part of the browser se it's a sand, it's sandboxed, it's execution sandbox. [00:52:17] Francois: That's, uh, the, the EME is kind of unique in, in this way where the, the CDM is not allowed to make network requests, for example, again, for privacy reasons. so anyway, the, the CDM box has the logic to decrypt the content and it hands it over, and then it depends, it depends on the level of protection you. [00:52:37] Francois: You need or that the system supports. It can be against software based protection, in which case actually, a highly motivated, uh, uh, uh, attacker could, uh, actually get access to the decoded stream, or it can be more hardware protected, in which case actually the, it goes to the, uh, to your final screen. [00:52:58] Francois: But it goes, it, it goes through the hardware in a, in a mode that the US supports in a mode that even the user agent doesn't have access to it. So it doesn't, it can't even see the pixels that, uh, gets rendered on the screen. There are, uh, several other, uh, APIs that you could use, for example, to take a screenshot of your, of your application and so on. [00:53:16] Francois: And you cannot apply them to, uh, such content because they're just gonna return a black box. again, because the user agent itself does not see the, uh, the pixels, which is exactly what you want with encrypted content. [00:53:29] Jeremy: And the, the content decryption module, it's, if I understand correctly, it's something that's shipped with the browsers, but you were saying is if you were to look at the public source code of Chromium or of Firefox, you would not see that implementation. Content Decryption Module (Widevine, PlayReady) [00:53:47] Francois: True. I mean, the, the, um, the typical examples are, uh, uh, widevine, so wide Vine. So interestingly, uh, speaking in theory, these, uh, systems could have been provided by anyone in practice. They've been provided by the browser vendors themselves. So Google has Wide Vine. Uh, Microsoft has something called PlayReady. Apple uh, the name, uh, escapes my, uh, sorry. They don't have it on top of my mind. So they, that's basically what they support. So they, they also own that code, but in a way they don't have to. And Firefox actually, uh, they, uh, don't, don't remember which one, they support among these three. but, uh, they, they don't own that code typically. [00:54:29] Francois: They provide a wrapper around, around it. Yeah, that's, that's exactly the, the crux of the, uh, issue that, people have with, uh, with DRMs, right? It's, uh, the fact that, uh, suddenly you have a bit of code running there that is, uh, that, okay, you can send box, but, uh, you cannot inspect and you don't have, uh, access to its, uh, source code. [00:54:52] Jeremy: That's interesting. So the, almost the entire browser is open source, but if you wanna watch a Netflix movie for example, then you, you need to, run this, this CDM, in addition to just the browser code. I, I think, you know, we've kind of covered a lot. Documenting what's available in browsers for developers [00:55:13] Jeremy: I wonder if there's any other examples or anything else you thought would be important to mention in, in the context of the W3C. [00:55:23] Francois: There, there's one thing which, uh, relates to, uh, activities I'm doing also at W3C. Um. Here, we've been talking a lot about, uh, standards and, implementations in browsers, but there's also, uh, adoption of these browser, of these technology standards by developers in general and making sure that developers are aware of what exists, making sure that they understand what exists and one of the, key pain points that people, uh. [00:55:54] Francois: Uh, keep raising on, uh, the web platform is first. Well, the, the, the web platform is unique in the sense that there are different implementations. I mean, if you, [00:56:03] Francois: Uh, anyway, there are different, uh, context, different run times where there, there's just one provided by the company that owns the, uh, the, the, the system. The web platform is implemented by different, uh, organizations. and so you end up the system where no one, there's what's in the specs is not necessarily supported. [00:56:22] Francois: And of course, MDN tries, uh, to document what's what's supported, uh, thoroughly. But for MDN to work, there's a hell of a lot of needs for data that, tracks browser support. And this, uh, this data is typically in a project called the Browser Compat Data, BCD owned by, uh, MDN as well. But, the Open Web Docs collective is a, uh, is, uh, the one, maintaining that, uh, that data under the hoods. [00:56:50] Francois: anyway, all of that to say that, uh, to make sure that, we track things beyond work on technical specifications, because if you look at it from W3C perspective, life ends when the spec reaches standards, uh, you know, candidate rec or rec, you could just say, oh, done with my work. but that's not how things work. [00:57:10] Francois: There's always, you need the feedback loop and, in order to make sure that developers get the information and can provide the, the feedback that standardization can benefit from and browser vendors can benefit from. We've been working on a project called web Features with browser vendors mainly, and, uh, a few of the folks and MDN and can I use and different, uh, different people, to catalog, the web in terms of features that speak to developers and from that catalog. [00:57:40] Francois: So it's a set of, uh, it's a set of, uh, feature IDs with a feature name and feature description that say, you know, this is how developers would, uh, understand, uh, instead of going too fine grained in terms of, uh, there's this one function call that does this because that's where you, the, the kind of support data you may get from browser data and MDN initially, and having some kind of a coarser grained, uh, structure that says these are the, features that make sense. [00:58:09] Francois: They talk to developers. That's what developers talk about, and that's the info. So the, we need to have data on these particular features because that's how developers are going approach the specs. Uh. and from that we've derived the notion of baseline badges that you have, uh, are now, uh, shown on MDN on can I use and integrated in, uh, IDE tool, IDE Tools such as visual, visual studio, and, uh, uh, libraries, uh, linked, some linters have started to, um, to integrate that data. [00:58:41] Francois: Uh, so, the way it works is, uh, we've been mapping these coarser grained features to BCDs finer grained support data, and from there we've been deriving a kind of a, a batch that says, yeah, this, this feature is implemented well, has limited availability because it's only implemented in one or two browsers, for example. [00:59:07] Francois: It's, newly available because. It was implemented. It's been, it's implemented across the main browser vendor, um, across the main browsers that people use. But it's recent, and widely available, which we try to, uh, well, there's been lots of discussion in the, in the group to, uh, come up with a definition which essentially ends up being 30 months after, a feature become, became newly available. [00:59:34] Francois: And that's when, that's the time it takes for the, for the versions of the, the different versions of the browser to propagate. Uh, because you, it's not because there's a new version of a, of a browser that, uh, people just, Ima immediately, uh, get it. So it takes a while, to propagate, uh, across the, uh, the, the user, uh, user base. [00:59:56] Francois: And so the, the goal is to have a, a, a signal that. Developers can rely on saying, okay, well it's widely available so I can really use that feature. And of course, if that doesn't work, then we need to know about it. And so we are also working with, uh, people doing so developer surveys such as state of, uh, CSS, state of HTML, state of JavaScript. [01:00:15] Francois: That's I guess, the main ones. But also we are also running, uh, MDN short surveys with the MDN people to gather feedback on. On the, on these same features, and to feed the loop and to, uh, to complete the loop. and these data is also used by, internally, by browser vendors to inform, prioritization process, their prioritization process, and typically as part of the interop project that they're also running, uh, on the site [01:00:43] Francois: So a, a number of different, I've mentioned, uh, I guess a number of different projects, uh, coming along together. But that's the goal is to create links, across all of these, um, uh, ongoing projects with a view to integrating developers, more, and gathering feedback as early as possible and inform decision. [01:01:04] Francois: We take at the standardization level that can affect the, the lives of the developers and making sure that it's, uh, it affects them in a, in a positive way. [01:01:14] Jeremy: just trying to understand, 'cause you had mentioned that there's the web features and the baseline, and I was, I was trying to picture where developers would actually, um, see these things. And it sounds like from what you're saying is W3C comes up with what stage some of these features are at, and then developers would end up seeing it on MDN or, or some other site. [01:01:37] Francois: So, uh, I'm working on it, but that doesn't mean it's a W3C thing. It's a, it's a, again, it's a, we have different types of group. It's a community group, so it's the Web DX Community group at W3C, which means it's a community owned thing. so that's why I'm mentioning a working with a representative from, and people from MDN people, from open Web docs. [01:02:05] Francois: so that's the first point. The second point is, so it's, indeed this data is now being integrated. If you, and you look, uh, you'll, you'll see it in on top of the MDN pages on most of them. If you look at, uh, any kind of feature, you'll see a, a few logos, uh, a baseline banner. and then can I use, it's the same thing. [01:02:24] Francois: You're going to get a baseline, banner. It's more on, can I use, and it's meant to capture the fact that the feature is widely available or if you may need to pay attention to it. Of course, it's a simplification, and the goal is not to the way it's, the way the messaging is done to developers is meant to capture the fact that, they may want to look, uh, into more than just this, baseline status, because. [01:02:54] Francois: If you take a look at web platform tests, for example, and if you were to base your assessment of whether a feature is supported based on test results, you'll end up saying the web platform has no supported technology because there are absolutely no API that, uh, where browsers pass 100% of the, of the, of the test suite. [01:03:18] Francois: There may be a few of them, I don't know. But, there's a simplification in the, in the process when a feature is, uh, set to be baseline, there may be more things to look at nevertheless, but it's meant to provide a signal that, uh, still developers can rely on their day-to-day, uh, lives. [01:03:36] Francois: if they use the, the feature, let's say, as a reasonably intended and not, uh, using to advance the logic. [01:03:48] Jeremy: I see. Yeah. I'm looking at one of the pages on MDN right now, and I can see at the top there's the, the baseline and it, it mentions that this feature works across many browsers and devices, and then they say how long it's been available. And so that's a way that people at a glance can, can tell, which APIs they can use. [01:04:08] Francois: it also started, uh, out of a desire to summarize this, uh, browser compatibility table that you see at the end of the page of the, the bottom of the page in on MDN. but there are where developers were saying, well, it's, it's fine, but it's, it goes too much into detail. So we don't know in the end, can we, can we use that feature or can we, can we not use that feature? [01:04:28] Francois: So it's meant as a informed summary of, uh, of, of that it relies on the same data again. and more importantly, we're beyond MDN, we're working with tools providers to integrate that as well. So I mentioned the, uh, visual Studio is one of them. So recently they shipped a new version where when you use a feature, you can, you can have some contextual, uh. [01:04:53] Francois: A menu that tells you, yeah, uh, that's fine. You, this CSS property, you can, you can use it, it's widely available or be aware this one is limited Availability only, availability only available in Firefox or, or Chrome or Safari work kit, whatever. [01:05:08] Jeremy: I think that's a good place to wrap it up, if people want to learn more about the work you're doing or learn more about sort of this whole recommendations process, where, where should they head? [01:05:23] Francois: Generally speaking, we're extremely open to, uh, people contributing to the W3C. and where should they go if they, it depends on what they want. So I guess the, the in usually where, how things start for someone getting involved in the W3C is that they have some

In this repeat episode, Chris Coyier, co-founder of CodePen, talks about the evolving landscape of HTML heading into 2025. He delves into topics like the slow evolution of HTML compared to CSS and JavaScript, the importance of backwards compatibility, new HTML elements and pseudo-elements, and the potential of declarative shadow DOM for server-side rendering in web components. Links Website: https://chriscoyier.net Codepen: https://codepen.io/chriscoyier Frontend Social: https://front-end.social/@chriscoyier Github: https://github.com/chriscoyier Threads: https://www.threads.net/@chriscoyier Bluesky: https://bsky.app/profile/chriscoyier.net We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Em, at emily.kochanek@logrocket.com (mailto:emily.kochanek@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Chris Coyier.

Anthony Fu, Framework Developer at Nuxt Labs, discusses the shift to ESM-only formats in JavaScript development. He covers the controversy surrounding ESM, the advantages of moving from CJS to ESM, and what this transition means for the future of web development. Tune in to learn why now is the ideal time for this change, and how it benefits developers! Links https://antfu.me https://bsky.app/profile/antfu.me https://github.com/antfu https://x.com/antfu7 https://www.linkedin.com/in/antfu https://antfu.me/posts/move-on-to-esm-only We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Anthony Fu.

Chris Coyier, co-founder of CodePen, talks about the evolving landscape of HTML heading into 2025. He delves into topics like the slow evolution of HTML compared to CSS and JavaScript, the importance of backwards compatibility, new HTML elements and pseudo-elements, and the potential of declarative shadow DOM for server-side rendering in web components. Links https://chriscoyier.net https://codepen.io/chriscoyier https://front-end.social/@chriscoyier https://github.com/chriscoyier https://www.threads.net/@chriscoyier https://bsky.app/profile/chriscoyier.net We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Chris Coyier.

Hey, everyone. Welcome back to another exciting episode of JavaScript Jabber, part of the Top End Devs Network. I'm your host, Charles Max Wood, joined by our amazing panelist, Dan Shappir. In this episode, we dive into the latest developments in the world of JavaScript as we kick off a new year. You might recall we covered this topic about a year and a half ago in episode 590.  Today, we're revisiting the updates to see what's progressed and what's newly introduced in the JavaScript standard.Dan Shappir offers his expertise as we explore features that have recently been added to the language. From promise.allSettled, a feature that's been around for about five years but often underutilized, to array method enhancements like .at and Object.hasOwn, there's a ton to unpack. We'll also delve into exciting new library additions like findLast for arrays, efficient array copying methods and improvements in set operations that make JavaScript more powerful and developer-friendly than ever.The episode isn't just about the features that have already landed; we'll also touch on what's in the pipeline with proposals in various stages of development, including exciting concepts like temporal for better date and time handling. Whether you're a JavaScript pro or just keen to stay updated on the latest trends, this discussion is packed with insights to level up your coding game.So, grab your headphones, stay tuned, and let's explore the exciting world of new JavaScript features together!Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Join us on PodRocket's yearly wrap-up episode as Emily and our hosts— Paige, Noel, Josh, and Paul—discuss significant tech trends of 2024 and predictions for 2025. Topics include AI advancements, React development, the potential impact of Void0, and the controversy surrounding Oracle's JavaScript trademark. Links Paige https://www.paigeniedringhaus.com https://x.com/pniedri https://paigen11.medium.com https://dev.to/paigen11 https://github.com/paigen11 Noel https://bsky.app/profile/noel.minc.how Josh https://bsky.app/profile/joshuakgoldberg.com https://x.com/JoshuaKGoldberg https://hi.joshuakgoldberg.com https://github.com/JoshuaKGoldberg https://fosstodon.org/@JoshuaKGoldberg https://www.twitch.tv/JoshuaKGoldberg https://www.youtube.com/@JoshuaKGoldberg Paul https://www.linkedin.com/in/paul-mikulskis-37a50b4a/ We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)

W świecie technologii frontendowych, w najprostszym rozumieniu moduł może być najmniejszą cząstką aplikacji, zajmującą się jedną podstawową rzeczą, dodatkowo wydzieloną do osobnego miejsca. Ale aby nie było zbyt prosto, to tylko jedna z często stosowanych definicji modułu.W dzisiejszym odcinku gościem Tomka Ducina, specjalisty z zakresu architektury frontendu jest Tomasz Jakut, szerzej znany w społeczności JavaScriptowej jako Comandeer.Więcej na stronie tego odcinka na stronie bettersoftwaredesign.pl.

In this episode of the JavaScript Master Podcast, we're thrilled to welcome Tomasz Ducin, an Independent Consultant, Software Architect, Speaker, Trainer, and Co-Founder of Architektura Na Froncie, based in Warsaw, Poland. Join us as we dive deep into the fascinating world of JavaScript generators! Tomasz shares why generators are an essential topic right now and breaks down the key differences between generators and regular functions. We'll explore how generators enable lazy evaluation in JavaScript, the difference between generators and iterators, and why understanding the iteration protocol is crucial for modern JavaScript developers. We also discuss the ECMAScript proposal for generators, its potential impact on the future of JavaScript, and what this means for the code we write today and tomorrow. If you're eager to master generators and boost your JS performance, this episode is for you! Tune in and uncover the "superpowers" of JavaScript generators with us!

Kicking off the discussion is the release of Vue 3.5. Although it's not a major release, Vue 3.5 packs some great new features and optimizations like: reactivity system improvements (up to 56% less memory usage for apps than before), reactive prop destructuring stabilization (it's simpler to declare props with default values), and SSR improvements like lazy hydration for async components.RedwoodJS is also out with a new version, and 8.0 packs a wallop. It makes RedwoodJS the third framework to support React Server Components behind Next.js and Waku.The shadcn CLI has gotten an update as well where it can spin up a brand new Next.js app with shadcn and Tailwind configured and ready to go. Additionally, shadcn has integrated more tightly with Vercel's v0 AI code generator, and now every shadcn component is editable on v0, so users can customize the components in natural language and paste it into their apps afterwards. Pretty amazing!The TC39 Committee responsible for evaluating what new features get added to the JavaScript language has added a new intermediate step for proposals: step 2.7. By the time new proposals reach step 3, they must already have full test suites to support their implementation, and if, for any reason, they must go back to step 2 to rethink things, a lot of that work can be for naught.News:Paige - Vue 3.5 is outJack - RedwoodJS 8.0 and shadcn CLI updatesTJ - JavaScript Standard Gets an Extra StageList of ECMAScript proposals on GitHubBonus News:Laravel raises $57 million series ASSR benchmark wars update (author Matteo is the Fastify lead maintainer)What Makes Us Happy this Week:Paige - House of the Dragon season 2Jack - Raspberry Pi TJ - Linkin Park is back!Thanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or Tweet us on X @front_end_fire.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fire

Node.js makes big TypeScript & SQLite moves, ECMAScript 2024 adds some niceties to the language (but not the ones you're probably excited for) & we review the State of React 2023 results. Emergency?! Nick!

Node.js makes big TypeScript & SQLite moves, ECMAScript 2024 adds some niceties to the language (but not the ones you're probably excited for) & we review the State of React 2023 results. Emergency?! Nick!

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 20/04 a 26/04.

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 20/04 a 26/04.

Es gibt einiges Neues aus der JavaScript-Welt! Fabi berichtet uns von Kuto, einem neuen JavaScript-Post-Processor, der durch geschicktes Aufteilen eures Codes und geschickten Cachings bessere Performance verspricht – insbesondere für wiederkehrende Besucher:innen eurer Websites.Außerdem war Jan auf der Google Cloud Next in Las Vegas und berichtet von den neuesten Entwicklungen im Bereich von Googles LLMs, Software und Hardware. Außerdem sprechen Fabi und Jan darüber, wie wirtschaftlich der Betrieb großer Sprachmodelle langfristig ist.Wer sich schon immer an der Kalkulation von Zeitzonen erfreut hat, hat jetzt noch mehr Grund zum Jubeln. Denn mit der Coordinated Lunar Time (LTC) soll für den Mond eine eigene Zeitzone geschaffen werden.Wesentlich praxisnäher ist da schon das neue ECMAScript Proposal für eine native Implementierung von Signals in JavaScript. Fabi erklärt, was das Signal Pattern ist und warum eine Standard-Implementierung hier sinnvoll sein kann.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTube

En este vídeo podcast vamos a repasar la historia de JavaScript. Desde sus humildes comienzos, programado en tan solo 10 días como LiveScript, hasta ser el lenguaje de programación más utilizado del mundo, pasando por sus evoluciones, estándares, superlenguajes, frameworks... José Manuel Alarcón Aguín te cuenta un montón de detalles interesantes, desde el punto de vista de alguien que vivió esta historia completa desde sus inicios. ENLACES: Curso Avanzado de JavaScript de campusMVP.es (¡soy el autor y tutor!): https://www.campusmvp.es/catalogo/Product-Programaci%C3%B3n-avanzada-con-JavaScript-y-ECMAScript_206.aspx El primer Roll-Over: https://joemaller.com/javascript/doubleroll.shtml WAT: https://www.destroyallsoftware.com/talks/wat

Show DescriptionA follow up on jQuery conversation, Microsoft owning all the things, what VS Code plugins are your ride or die, the ability to Git from wherever you want, Tailwind drama, global design system follow up, Arc Search gets roasted, and Frontend Design Conference is back! Listen on Website →Links GitHub - tc39/proposal-type-annotations: ECMAScript proposal for type syntax that is erased - Stage 1 Chris Coyier on Embracing Technology and the Future of Web Development - Whiskey Web and Whatnot - Episode 131 Zed Dracula Official GitLens Tower Git Client GitHub Desktop “Wherever you get your podcasts” is a radical statement - Anil Dash Sourcetree Tailwind marketing and misinformation engine What is Utility-First CSS?: HeydonWorks A Global Design System | Brad Frost Thoughts on a Global Design System – Chris Coyier Arc Search Can Apple Win Back Music - Brad Frost Carolina Chocolate Drops TPAIN - Twitch Front-end Design Conference - April 25-26, 2024 SponsorsWixWix Studio combines pure web design with maximum productivity. Taking the grind out of website creation for professional designers. Use the powerful visual editor, or work online in a VS Code-based IDE, or code locally and push changes via GitHub.

En el episodio 2.9 os hablamos de streamear en Twitch, de la IA que predice tu muerte, del espacio de color OKLCH y CSS4, de los resultados de las encuestas State of Web development y State of Components, de lo nuevo en Astro 4.0, de Google Gemini y Bard leyendo videos de YouTube, del recap de las funcionalidades de ECMAScript 2023, de Amazon entregando coches a domicilio en su globo, de Google y McDonald planeando una nueva hamburguesa juntos, de nuevos recursos sobre Web Performance, de Adobe rompiendo el corazón a Figma, entre otras muchas cosas

In this episode of Syntax, Wes and Scott review their 2023 predictions and see how they did on ideas like Deno getting hotter, new JS APIs, WASM, Houdini, CSS Container Queries, and more! Show Notes 00:24 Welcome 01:18 Syntax Brought to you by Sentry 02:05 SSR JS sites more the norm solidjs.com Remix - Build Better Websites Next.js by Vercel - The React Framework SvelteKit • Web development, streamlined Astro 04:14 TypeScript Inferred becomes hot 05:20 Types In JS? ECMAScript proposal for type syntax that is erased - Stage 1 07:55 Deno gets hotter 11:12 JS runtimes mature htmx 11:50 We will see a new TS Type Checker written in Rust 14:06 New JS APIs What's the status of this project? · Issue #1101 · dudykr/stc Wes Bos on X: "Pretty excited about the new JavaScript non-mutating array methods. Currently in stage 3 tc39/proposals: Tracking ECMAScript Proposals JS Fundamentals - Decorators - Syntax #653 16:29 Writing towards Winter CG Spec Popular. WinterCG 17:09 Edge Rendering More Common Prettier on X: "We setup a $20k bounty for a rust-based compatible printer with prettier. $20k Bounty was Claimed! · Prettier 18:09 A new JS framework 19:05 Page Transitions API 19:51 Rust becomes more popular 24:00 More WASM Supper Club × WASM, Fastly Edge, and Polyfill.io with Jake Champion - Syntax #643 FFmpeg Fastly 25:11 React Beta Docs launch after 5 year dev cycle 26:47 We start to see CSS Container Queries in production 29:05 CanIUse issues? 31:20 CSS Subgrid 32:56 More AI 34:06 Tooling Vite | Next Generation Frontend Tooling Announcing Biome | Biome Lightning CSS Rspack Turbopack 36:08 People sour on React 36:47 People sour on eslint 37:16 Houdini does nothing CSS Houdini| MDN Is Houdini Ready Yet? 39:57 How'd we do? 40:40 Sick picks Sick Picks Scott: Super Mario Bros.™ Wonder Wes: Tineco Pure ONE S11 Cordless Vacuum Cleaner Shameless Plugs Scott: Sentry Wes: Wes Bos Courses Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads

Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching. Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community. An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course. This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family. Epic Web (https://www.epicweb.dev/) Remix (https://remix.run/) Follow Kent C. Dodds on LinkedIn (https://www.linkedin.com/in/kentcdodds/) or X (https://twitter.com/kentcdodds). Visit his website at kentcdodds.com (https://kentcdodds.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me. KENT: Thank you so much for having me. It's an honor to be here. WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you. KENT: Oh, thank you. WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that. KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can. So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life. And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry. I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that. I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher. WILL: Wow. Yes, I definitely have questions around that. KENT: [laughs] Okay. WILL: So many. But I want to start back...you were saying you have four kids. What are their ages? KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child. WILL: [chuckles] KENT: So, we're, like, starting a new family, or [laughs] something. WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing. KENT: Thank you. WILL: Yeah. How are you feeling about that gap? KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything. Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one. WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart. KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs]. WILL: Wow. You're the first one I've heard that their kids share a birthday. KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family. WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11? KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11. WILL: Okay, how was that growing up with that many siblings? KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six. I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun. WILL: Yeah. My mom, she had 12 brothers and sisters. KENT: Whoa. WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was -- KENT: [laughs] WILL: We loved it [laughs]. KENT: Yeah, that's wonderful. I love that. WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev? KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all. And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos. My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that. And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming. Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that." I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad. And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter]. And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming. The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff. And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do. So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that. WILL: [laughs] KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers. What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff. And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun. And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could. WILL: [laughs] KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end. WILL: Oh, wow. KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java. It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so… WILL: What year was that? KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app. And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better. WILL: [laughs] KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs]. WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing. KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer. WILL: [laughs] KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing. Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it. WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like? KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say -- WILL: [laughs] KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates. This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense. WILL: [laughs] KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing. And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years. But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something. WILL: Wow. KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion. WILL: [laughs] KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage. WILL: Wow. KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day. WILL: [laughs] KENT: And I just need some alone time." WILL: Yes. KENT: And so, I was like, okay. WILL: [laughs] KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences. In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk. WILL: Whoa. KENT: Which was, yeah, that was wild. WILL: [laughs] KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary. WILL: Oh wow. KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript. WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it. So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion? KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook. There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit. But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that. There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too. WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments? KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS. And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work. Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that. There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways. WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that. KENT: Yeah, 100%. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful? KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing. And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco. WILL: Oh, wow. KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing. WILL: [laughs] KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that. And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that. What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular. The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing. And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great." I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November. And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so... WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing. KENT: Aw, thank you so much. WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did? KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React. And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad. Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody. But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as. But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises. And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise. So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that. WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct? KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together. And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does. So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React. I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website. My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project. And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements." And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is." So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix." And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them. I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago. So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously." And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake. And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here. So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me." And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things. On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you? And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell. And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun. As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that. And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify. WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct? KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea. Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU. And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did. Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea. So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time. Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs]. I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops. And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do. And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing. One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync. And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go. So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong. It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it. So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that. But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React. But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment. So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan. But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack. And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff. So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack. And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that. And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation. Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May. And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days." And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging. The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops. Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops. And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October. For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff? But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that. The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by

In this episode of Syntax, Wes and Scott talk through new and proposed JavaScript APIs including ones related to regex, sourcemaps, structured clone, temporal, JSON modules, and more! Show Notes 00:10 Welcome 01:26 Syntax Brought to you by Sentry 02:55 RegExp Escaping Proposal tc39/proposal-regex-escaping: Proposal for investigating RegExp escaping for the ECMAScript standard 05:25 Intl.DurationFormat tc39/proposal-intl-duration-format 07:55 Standardized Sourcemaps tc39/source-map-rfc: RFCs for the source map debug format. 10:43 Structured Clone structuredClone() global function - Web APIs | MDN 12:54 Temporal Hasty Treat - Temporal Date Objects in JavaScript Tracking issue for syncing with IETF standardization work (req'd before implementers can ship unflagged) · Issue #1450 · tc39/proposal-temporal 20:59 FindLast and findLastIndex tc39/proposal-array-find-from-last: Proposal for Array.prototype.findLast and Array.prototype.findLastIndex. 22:27 JSON modules tc39/proposal-json-modules: Proposal to import JSON files as modules 24:46 Regex Modifiers RegExp Modifiers - June 2022.pptx - Microsoft PowerPoint Online 26:50 Array Grouping tc39/proposal-array-grouping: A proposal to make grouping of array items easier 30:48 Array Methods tc39/proposal-change-array-by-copy: Provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change. 6 or so New Approved and Proposed JavaScript APIs 32:12 Promise.withResolvers 35:08 Function.prototype.memo tc39/proposal-function-memo: A TC39 proposal for function memoization in the JavaScript language. 37:48 Node has a Proposed ESM Detection flag 39:54 Node has navigator.userAgent 41:29 Built in .env support 42:52 Permissions model & test runner continues to be worked on 44:06 HTML Web charts Proposal: Web Charts · Issue #9295 · whatwg/html 45:39 autopause Add autopause attribute to media elements to allow automatic pausing of media · Issue #9793 · whatwg/html 46:30 Meta Tag for AI generated content Proposal: Meta Tag for AI Generated Content · Issue #9479 · whatwg/html Schema.org - Schema.org Syntax × Sentry Swag Store – Syntax × Sentry Shop Syntax - A Tasty Treats Podcast for Web Developers. 50:13 Poster frame HTML Video Element: Proposal for adding [srcset] + [posterset] + [sizes] on video element as well [posterset] on source elements · Issue #9812 · whatwg/html 50:57 Popover invoker Popover does not know what triggered it · Issue #9111 · whatwg/html 51:25 Autocomplete on ‘contenteditable' Elements Autocomplete on ‘contenteditable' Elements · Issue #9065 · whatwg/html 52:17 Sick Picks Sick Picks Scott: Escaping Twin Flames cult documentary Wes: Lao Gan Ma spicy Chili Oil Shameless Plugs Scott: Sentry Wes: Wes Bos Courses Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads

Mark S. Miller is the Chief Scientist at Agoric. He is a pioneer of agoric (market-based secure distributed) computing and smart contracts, the main designer of the E and Dr. SES distributed persistent object-capability programming languages, inventor of Miller Columns, an architect of the Xanadu hypertext publishing system, a representative of the ECMAScript committee, a former Google research scientist, and member of the WebAssembly (Wasm) group.Key HighlightsThis podcast addresses common misconceptions about the risks of advanced AI – an example being the paper clip scenarioHow more pressing concerns regard one entity gaining unchecked power and that solutions lie not in just dispersing power but in structuring institutions effectively – similar to the separation of powers principle.The blend of human and AI intelligence is the cornerstone of future civilization, demanding innovative governance to ensure harmony.Dive deeper into the session: Full SummaryThe Foresight InstituteA research organization and non-profit that supports the beneficial development of high-impact technologies. Since our founding in 1987 with a vision of guiding powerful technologies, we have continued to evolve into a many-armed organization that focuses on several fields of science and technology that are too ambitious for legacy institutions to support.Allison DuettmannThe President and CEO of Foresight Institute, Allison Duettmann directs the Intelligent Cooperation, Molecular Machines, Biotech & Health Extension, Neurotech, and Space Programs, alongside Fellowships, Prizes, and Tech Trees. She has also been pivotal in co-initiating the Longevity Prize, pioneering initiatives like Existentialhope.com, and contributing to notable works like "Superintelligence: Coordination & Strategy" and "Gaming the Future".Get Involved with ForesightApply: Virtual Salons & in-person WorkshopsDonate: Support Our Work – If you enjoy what we do, please consider this, as your donations fund us entirely!Follow Us: Twitter | Facebook | LinkedInNote: Explore every word spoken on this podcast through Fathom.fm, an innovative podcast search engine. Hosted on Acast. See acast.com/privacy for more information.

JavaScript: Eine multiparadigmatische Skriptsprache mit einem schwachen dynamischen Ducktyping-System.Um die Sprache JavaScript kommt man im Web nicht mehr vorbei. Die meisten kennen sie durch Frameworks wie React, Angular, Vue.js, Next und Co. Doch wie viel weißt du über die Hintergründe und die Weiterentwicklung dieser Sprache?In dieser Episode geht es nicht um das nächste hippe JavaScript-Framework, sondern wir sprechen mit Peter Kröner darüber, wie JavaScript erfunden wurde, was ECMAScript ist, wie TypeScript in den Mix spielt, warum die Sprache so beliebt ist, wie neue Features den Weg in die Sprache finden, was das TC39 ist, über das Monopol im Browser, verschiedene JavaScript-Engines und viel mehr.Bonus: Wenn Hamburg im Süden liegt.**** Diese Episode wird gesponsert vom Open-Source Förderprogramm Media Tech Lab: Bewirb dich jetzt und erhalte bis zu 50.000€ Fördersumme für dein Open-Source Projekt https://www.media-lab.de/de/media-tech-labDas schnelle Feedback zur Episode:

En el episodio 2.4 os hablamos de VR, de streamear en Twitch, de los nuevos editores visuales de Vercel y Netlify, de animaciones en el scroll en CSS, de ECMAScript 2023, de las funcionalidades de ChatGPT: Code Interpreter y Voice Control, de Bard de Google, de la intro de Secret Invasion, de la (no)bienvenida al Figma Devmode, de la versión 3.4 de Tailwind con Oxide, de la nueva fuente de Microsoft office, del protocolo ActivityPub, entre otras muchas cosas

Dan and Steve join this week's panelist episode to talk about the TC39. Dan starts off as he explains the stages of adding features to the ECMAScript language specification to be added to the JavaScript language.SponsorsChuck's Resume TemplateDeveloper Book Club Become a Top 1% Dev with a Top End Devs MembershipLinksTC39 processTC39 ECMAScript proposalsUpcoming Proposals for ECMAScript (PART 1) - JSJ 532Stage 3: using keywords for automatic resource disposal (objects with lifetime)(Sync) Iterator Helpers intent to shipSet methodsDecorators (for Aspect Oriented Programming for the separation of cross-cutting concerns, e.g. logging and serialization)ShadowRealmsStage 2: Async Iterator HelpersIterator.rangeStage 1: do expressionsSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

In this supper club episode of Syntax, Wes and Scott talk with Nick Hehr about the fun ways to get started with micro controllers, writing JavaScript for hardware, and ideas for projects to build involving hardware and software. Show Notes 00:36 Welcome to Syntax 01:04 Introducing Nick Hehr Nick Hehr (@hipsterbrown) HipsterBrown (@hipsterbrown@toot.cafe) - Toot Café HipsterBrown HipsterBrown (Nick Hehr) Nick Hehr on CodePen 03:58 Running JavaScript on microcontrollers 06:20 What was your first project that got you into this? 12:12 Is the ESP32 the most popular controller? 14:12 Where do you buy hardware? Arduino - Home Adafruit Industries, Unique & fun DIY electronics and kits AliExpress - Online Shopping for Popular Electronics, Fashion, Home & Garden, Toys & Sports, Automobiles and More products - AliExpress SparkFun Electronics Introduction

Luca Casonato is the tech lead for Deno Deploy and a TC39 delegate. Deno is a JavaScript runtime from the original creator of NodeJS, Ryan Dahl. Topics covered: What's a JavaScript runtime How V8 is used Why Deno was created The W3C WinterCG for server-side JavaScript Why it's difficult to ship new features in Node The benefits of web standards Creating an all-inclusive toolset like Rust and Go Deno's node compatibility layer Use cases for WebAssembly Benefits and implementation of Deno Deploy Reasons to deploy on the edge What's coming next Luca Luca Casonato @lcasdev Deno Homepage Deploy Showcase Subhosting Fresh web framework The anatomy of an Isolate Cloud Deno Users Netlify Edge Functions Deno at Slack GitHub Flat Data Shopify Oxygen Other related links Cache Web API V8 (JavaScript and WebAssembly engine) TC39 (JavaScript specification group) Web-interoperable Runtimes Community Group (WinterCG) Cloudflare Workers (Deno Deploy competitor) How Cloudflare KV works CockroachDB (Distributed database) XKCD Standards Comic Transcript You can help edit this transcript on GitHub. [00:00:07] Jeremy: Today I'm talking to Luca Casonato. He's a member of the Deno Core team and a TC 39 Delegate. [00:00:06] Luca: Hey, thanks for having me. What's a runtime? [00:00:07] Jeremy: So today we're gonna talk about Deno, and on the website it says, Deno is a runtime for JavaScript and TypeScript. So I thought we could start with defining what a runtime is. [00:00:21] Luca: Yeah, that's a great question. I think this question actually comes up a lot. It's, it's like sometimes we also define Deno as a headless browser, or I don't know, a, a JavaScript script execution tool. what actually defines runtime? I, I think what makes a runtime a runtime is that it is a, it's implemented in native code. It cannot be self-hosted. Like you cannot self-host a JavaScript runtime. and it executes JavaScript or TypeScript or some other scripting language, without relying on, well, yeah, I guess it's the self-hosting thing. Like it's, it's essentially a, a JavaScript execution engine, which is not self-hosted. So yeah, it, it maybe has IO bindings, but it doesn't necessarily need to like, it. Maybe it allows you to read the, from the file system or, or make network calls. Um, but it doesn't necessarily have to. It's, I think the, the primary definition is something which can execute JavaScript without already being written in JavaScript. How V8 and JavaScript runtimes are related [00:01:20] Jeremy: And when we hear about JavaScript run times, whether it's Deno or Node or Bun, or anything else, we also hear about it in the context of v8. Could you explain the relationship between V8 and a JavaScript run time? [00:01:36] Luca: Yeah. So V8 and, and JavaScript core and Spider Monkey, these are all JavaScript engines. So these are the low level virtual machines that can execute or that can parse your JavaScript code. turn it into byte code, maybe turn it into, compiled machine code, and then execute that code. But these engines, Do not implement any IO functions. They do not. They implement the JavaScript spec as is written. and then they provide extension hooks for, they call these host environments, um, like environments that embed these engines to provide custom functionalities to essentially poke out of the sandbox, out of the, out of the virtual machine. Um, and this is used in browsers. Like browsers have, have these engines built in. This is where they originated from. Um, and then they poke holes into this, um, sandbox virtual machine to do things like, I don't know, writing to the dom or, or console logging or making fetch calls and all these kinds of things. And what a runtime essentially does, a JavaScript runtime is it takes one of these engines and. It then provides its own set of host APIs, like essentially its own set of holes. It pokes into the sandbox. and depending on what the runtime is trying to do, um, the weight will do. This is gonna be different and, and the sort of API that is ultimately exposed to the end user is going to be different. For example, if you compare Deno and node, like node is very loosey goosey, about how it pokes holds into the sandbox, it sort of just pokes them everywhere. And this makes it difficult to enforce things like, runtime permissions for example. Whereas Deno is much more strict about how it, um, pokes holds into its sandbox. Like everything is either a web API or it's behind in this Deno name space, which means that it's, it's really easy to find, um, places where, where you're poking out of the sandbox. and really you can also compare these to browsers. Like browsers are also JavaScript run times. Um, they're just not headless. JavaScript run times, but JavaScript run times that also have a ui. and. . Yeah. Like there, there's, there's a whole Bunch of different kinds of JavaScript run times, and I think we're also seeing a lot more like embedded JavaScript run times. Like for example, if you've used React Native before, you, you may be using Hermes as a, um, JavaScript engine in your Android app, which is like a custom JavaScript engine written just for, for, for React native. Um, and this also is embedded within a, like react native run time, which is specific to React native. so it's also possible to have run times, for example, that are, that can be where the, where the back backing engine can be exchanged, which is kind of cool. [00:04:08] Jeremy: So it sounds like V8's role, one way to look at it is it can execute JavaScript code, but only pure functions. I suppose you [00:04:19] Luca: Pretty much. Yep. [00:04:21] Jeremy: Do anything that doesn't interact with IO so you think about browsers, you were mentioning you need to interact with a DOM or if you're writing a server side application, you probably need to receive or make HTTP requests, that sort of thing. And all of that is not handled by v8. That has to be handled by an external runtime. [00:04:43] Luca: Exactly Like, like one, one. There's, there's like some exceptions to this. For example, JavaScript technically has some IO built in with, within its standard library, like math, random. It's like random number. Generation is technically an IO operation, so, Technically V8 has some IO built in, right? And like getting the current date from the user, that's also technically IO So, like there, there's some very limited edge cases. It's, it's not that it's purely pure, but V8 for example, has a flag to turn it completely deterministic. which means that it really is completely pure. And this is not something which run times usually have. This is something like the feature of an engine because the engine is like so low level that it can essentially, there's so little IO that it's very easy to make deterministic where a runtime higher level, um, has, has io, um, much more difficult to make deterministic. [00:05:39] Jeremy: And, and for things like when you're working with JavaScript, there's, uh, asynchronous programming [00:05:46] Luca: mm-hmm. Concurrent JavaScript execution [00:05:47] Jeremy: So you have concurrency and things like that. Is that a part of V8 or is that the responsibility of the run time? [00:05:54] Luca: That's a great question. So there's multiple parts to this. There's the part, um, there, there's JavaScript promises, um, and sort of concurrent Java or well, yes, concurrent JavaScript execution, which is sort of handled by v8, like v8. You can in, in pure v8, you can create a promise, and you can execute some code within that promise. But without IO there's actually no way to defer time, uh, which means that in with pure v8, you can either, you can create a promise. Which executes right now. Or you can create a promise that never executes, but you can't create a promise that executes in 10 seconds because there's no way to measure 10 seconds asynchronously. What run times do is they add something called an event loop on top of this, um, on top of the base engine and that event loop, for example, like a very simple event loop, for example, might have a timer in it, which every second looks at if there's a timer schedule to run within that second. And if it does, if, if that timer exists, it'll go call out to V8 and say, you can now execute that promise. but V8 is still the one that's keeping track of, of like which promises exist, and the code that is meant to be invoked when they resolve all that kind of thing. Um, but the underlying infrastructure that actually invokes which promises get resolved at what point in time, like the asynchronous, asynchronous IO is what this is called. This is driven by the event loop, um, which is implemented by around time. So Deno, for example, it uses, Tokio for its event loop. This is a, um, an event loop written in Rust. it's very popular in the Rust ecosystem. Um, node uses libuv. This is a relatively popular runtime or, or event loop, um, implementation for c uh, plus plus. And, uh, libuv was written for Node. Tokio was not written for Deno. But um, yeah, Chrome has its own event loop implementation. Bun has its own event loop implementation. [00:07:50] Jeremy: So we, we might go a little bit more into that later, but I think what we should probably go into now is why make Deno, because you have Node that's, uh, currently very popular. The co-creator of Deno, to my understanding, actually created Node. So maybe you could explain to our audience what was missing or what was wrong with Node, where they decided I need to create, a new runtime. Why create a new runtime? (standards compliance) [00:08:20] Luca: Yeah. So the, the primary point of concern here was that node was slowly diverging from browser standards with no real path to, to, to, re converging. Um, like there was nothing that was pushing node in the direction of standards compliance and there was nothing, that was like sort of forcing node to innovate. and we really saw this because in the time between, I don't know, 2015, 2018, like Node was slowly working on esm while browsers had already shipped ESM for like three years. , um, node did not have fetch. Node hasn't had, or node only at, got fetch last year. Right? six, seven years after browsers got fetch. Node's stream implementation is still very divergent from, from standard web streams. Node was very reliant on callbacks. It still is, um, like promises in many places of the Node API are, are an afterthought, which makes sense because Node was created in a time before promises existed. Um, but there was really nothing that was pushing Node forward, right? Like nobody was actively investing in, in, in improving the API of Node to be more standards compliant. And so what we really needed was a new like Greenfield project, which could demonstrate that actually writing a new server side run. Is A viable, and b is totally doable with an API that is more standards combined. Like essentially you can write a browser, like a headless browser and have that be an excellent to use JavaScript runtime, right? And then there was some things that were I on top of that, like a TypeScript support because TypeScript was incredibly, or is still incredibly popular. even more so than it was four years ago when, when Deno was created or envisioned, um, this permission system like Node really poked holes into the V8 sandbox very early on with, with like, it's gonna be very difficult for Node to ever, ever, uh, reconcile this, this. Especially cuz the, some, some of the APIs that it, that it exposes are just so incredibly low level that like, I don't know, you can mutate random memory within your process. Um, which like if you want to have a, a secure sandbox like that just doesn't work. Um, it's not compatible. So there was really needed to be a place where you could explore this, um, direction and, and see if it worked. And Deno was that. Deno still is that, and I think Deno has outgrown that now into something which is much more usable as, as like a production ready runtime. And many people do use it, in production. And now Deno is on the path of slowly converging back with Node, um, in from both directions. Like Node is slowly becoming more standards compliant. and depending on who you ask this was, this was done because of Deno and some people said it would had already been going on and Deno just accelerated it. but that's not really relevant because the point is that like Node is becoming more standard compliant and, and the other direction is Deno is becoming more node compliant. Like Deno is implementing node compatibility layers that allow you to run code that was originally written for the node ecosystem in the standards compliant run time. so through those two directions, the, the run times are sort of, um, going back towards each other. I don't think they'll ever merge. but we're, we're, we're getting to a point here pretty soon, I think, where it doesn't really matter what runtime you write for, um, because you'll be able to write code written for one runtime in the other runtime relatively easily. [00:12:03] Jeremy: If you're saying the two are becoming closer to one another, becoming closer to the web standard that runs in the browser, if you're talking to someone who's currently developing in node, what's the incentive for them to switch to Deno versus using Node and then hope that eventually they'll kind of meet in the middle. [00:12:26] Luca: Yeah, so I think, like Deno is a lot more than just a runtime, right? Like a runtime executes JavaScript, Deno executes JavaScript, it executes type script. But Deno is so much more than that. Like Deno has a built-in format, or it has a built-in linter. It has a built-in testing framework, a built-in benching framework. It has a built-in Bundler, it, it like can create self-hosted, um, executables. yeah, like Bundle your code and the Deno executable into a single executable that you can trip off to someone. Um, it has a dependency analyzer. It has editor integrations. it has, Yeah. Like I could go on for hours, (laughs) about all of the auxiliary tooling that's inside of Deno, that's not a JavaScript runtime. And also Deno as a JavaScript runtime is just more standards compliant than any of the other servers at Runtimes right now. So if, if you're really looking for something which is standards complaint, which is gonna like live on forever, then it's, you know, like you cannot kill off the Fetch API ever. The Fetch API is going to live forever because Chrome supports it. Um, and the same goes for local storage and, and like, I don't know, the Blob API and all these other web APIs like they, they have shipped and browsers, which means that they will be supported until the end of time. and yeah, maybe Node has also reached that with its api probably to some extent. but yeah, don't underestimate the power of like 3 billion Chrome users. that would scream immediately if the Fetch API stopped working Right? [00:13:50] Jeremy: Yeah, I, I think maybe what it sounds like also is that because you're using the API that's used in the browser places where you deploy JavaScript applications in the future, you would hope that those would all settle on using that same API so that if you were using Deno, you could host it at different places and not worry about, do I need to use a special API maybe that you would in node? WinterCG (W3C group for server side JavaScript) [00:14:21] Luca: Yeah, exactly. And this is actually something which we're specifically working towards. So, I don't know if you've, you've heard of WinterCG? It's a, it's a community group at the W3C that, um, CloudFlare and, and Deno and some others including Shopify, have started last year. Um, we're essentially, we're trying to standardize the concept of what a server side JavaScript runtime is and what APIs it needs to have available to be standards compliant. Um, and essentially making this portability sort of written down somewhere and like write down exactly what code you can write and expect to be portable. And we can see like that all of the big, all of the big players that are involved in, in, um, building JavaScript run times right now are, are actively, engaged with us at WinterCG and are actively building towards this future. So I would expect that any code that you write today, which runs. in Deno, runs in CloudFlare, workers runs on Netlify Edge functions, runs on Vercel's Edge, runtime, runs on Shopify Oxygen, is going to run on the other four. Um, of, of those within the next couple years here, like I think the APIs of these is gonna converge to be essentially the same. there's obviously gonna always be some, some nuances. Um, like, I don't know, Chrome and Firefox and Safari don't perfectly have the same API everywhere, right? Like Chrome has some web Bluetooth capabilities that Safari doesn't, or Firefox has some, I don't know, non-standard extensions to the error object, which none of the other runtimes do. But overall you can expect these front times to mostly be aligned. yeah, and I, I think that's, that's really, really, really excellent and that, that's I think really one of the reasons why one should really consider, like building for, for this standard runtime because it, it just guarantees that you'll be able to host this somewhere in five years time and 10 years time, with, with very little effort. Like even if Deno goes under or CloudFlare goes under, or, I don't know, nobody decides to maintain node anymore. It'll be easy to, to run somewhere else. And also I expect that the big cloud vendors will ultimately, um, provide, manage offerings for, for the standards compliant JavaScript on time as well. Is Node part of WinterCG? [00:16:36] Jeremy: And this WinterCG group is Node a part of that as well? [00:16:41] Luca: Um, yes, we've invited Node, um, to join, um, due to the complexities of how node's, internal decision making system works. Node is not officially a member of WinterCG. Um, there is some individual members of the node, um, technical steering committee, which are participating. for example, um, James m Snell is, is the co-chair, is my co-chair on, on WinterCG. He also works at CloudFlare. He's also a node, um, TSC member, Mateo Colina, who has been, um, instrumental to getting fetch landed in Node, um, is also actively involved. So Node is involved, but because Node is node and and node's decision making process works the way it does, node is not officially listed anywhere as as a member. but yeah, they're involved and maybe they'll be a member at some point. But, yeah, let's. , see (laughs) [00:17:34] Jeremy: Yeah. And, and it, so it, it sounds like you're thinking that's more of a, a governance or a organizational aspect of note than it is a, a technical limitation. Is that right? [00:17:47] Luca: Yeah. I obviously can't speak for the node technical steering committee, but I know that there's a significant chunk of the node technical steering committee that is, very favorable towards, uh, standards compliance. but parts of the Node technical steering committee are also not, they are either indifferent or are actively, I dunno if they're still actively working against this, but have actively worked against standards compliance in the past. And because the node governance structure is very, yeah, is, is so, so open and let's, um, and let's, let's all these voices be heard, um, that just means that decision making processes within Node can take so long, like. . This is also why the fetch API took eight years to ship. Like this was not a technical problem. and it is also not a technical problem. That Node does not have URL pattern support or, the file global or, um, that the web crypto API was not on this, on the global object until like late last year, right? Like, these are not technical problems, these are decision making problems. Um, and yeah, that was also part of the reason why we started Deno as, as like a separate thing, because like you can try to innovate node, from the inside, but innovating node from the inside is very slow, very tedious, and requires a lot of fighting. And sometimes just showing somebody, from the outside like, look, this is the bright future you could have, makes them more inclined to do something. Why it takes so long to ship new features in Node [00:19:17] Jeremy: Do, do you have a sense for, you gave the example of fetch taking eight years to, to get into node. Do you, do you have a sense of what the typical objection is to, to something like that? Like I, I understand there's a lot of people involved, but why would somebody say, I, I don't want this [00:19:35] Luca: Yeah. So for, for fetch specifically, there was a, there was many different kinds of concerns. Um, one of the, I, I can maybe list two of them. One of them was for example, that the fetch API is not a good API and as such, node should not have it. which is sort of. missing the point of, because it's a standard API, how good or bad the API is is much less relevant because if you can share the API, you can also share a wrapper that's written around the api. Right? and then the other concern was, node does need fetch because Node already has an HTTP API. Um, so, so these are both kind of examples of, of concerns that people had for a long time, which it took a long time to either convince these people or, or to, push the change through anyway. and this is also the case for, for other things like, for example, web, crypto, um, like why do we need web crypto? We already have node crypto, or why do we need yet another streams? Implementation node already has four different streams implementations. Like, why do we need web streams? and the, the. Like, I don't know if you know this XKCD of, there's 14 competing standards. so let's write a 15th standard, to unify them all. And then at the end we just have 15 competing standards. Um, so I think this is also the kind of concern that people were concerned about, but I, I think what we've seen here is that this is really not a concern that one needs to have because it ends up that, or it turns out in the end that if you implement web APIs, people will use web APIs and will use web APIs only for their new code. it takes a while, but we're seeing this with ESM versus require like new code written with require much less common than it was two years ago. And, new code now using like Xhr, whatever it's called, form request or. You know, the one, I mean, compared to using Fetch, like nobody uses that name. Everybody uses Fetch. Um, and like in Node, if you write a little script, like you're gonna use Fetch, you're not gonna use like Nodes, htp, dot get API or whatever. and we're gonna see the same thing with Readable Stream. We're gonna see the same thing with Web Crypto. We're gonna see, see the same thing with Blob. I think one of the big ones where, where Node is still, I, I, I don't think this is one that's ever gonna get solved, is the, the Buffer global and Node. like we have the Uint8, this Uint8 global, um, and like all the run times including browsers, um, and Buffer is like a super set of that, but it's in global scope. So it, it's sort of this non-standard extension of unit eight array that people in node like to use and it's not compatible with anything else. Um, but because it's so easy to get at, people use it anyway. So those are, those are also kind of problems that, that we'll have to deal with eventually. And maybe that means that at some point the buffer global gets deprecated and I don't know, probably can never get removed. But, um, yeah, these are kinds of conversations that the no TSE is going have to have internally in, I don't know, maybe five years. Write once, have it run on any hosting platform [00:22:37] Jeremy: Yeah, so at a high level, What's shipped in the browser, it went through the ECMAScript approval process. People got it into the browser. Once it's in the browser, probably never going away. And because of that, it's safe to build on top of that for these, these server run times because it's never going away from the browser. And so everybody can kind of use it into the future and not worry about it. Yeah. [00:23:05] Luca: Exactly. Yeah. And that's, and that's excluding the benefit that also if you have code that you can write once and use in both the browser and the server side around time, like that's really nice. Um, like that, that's the other benefit. [00:23:18] Jeremy: Yeah. I think that's really powerful. And that right now, when someone's looking at running something in CloudFlare workers versus running something in the browser versus running something in. it's, I think a lot of people make the assumption it's just JavaScript, so I can use it as is. But it, it, there are at least currently, differences in what APIs are available to you. [00:23:43] Luca: Yep. Yep. Why bundle so many things into Deno? [00:23:46] Jeremy: Earlier you were talking about how Deno is more than just the runtime. It has a linter, formatter, file watcher there, there's all sorts of stuff in there. And I wonder if you could talk a little bit to the, the reasoning behind that [00:24:00] Luca: Mm-hmm. [00:24:01] Jeremy: Having them all be separate things. [00:24:04] Luca: Yeah, so the, the reasoning here is essentially if you look at other modern run time or mo other modern languages, like Rust is a great example. Go is a great example. Even though Go was designed around the same time as Node, it has a lot of these same tools built in. And what it really shows is that if the ecosystem converges, like is essentially forced to converge on a single set of built-in tooling, a that built-in tooling becomes really, really excellent because everybody's using it. And also, it means that if you open any project written by any go developer, any, any rest developer, and you look at the tests, you immediately understand how the test framework works and you immediately understand how the assertions work. Um, and you immediately understand how the build system works and you immediately understand how the dependency imports work. And you immediately understand like, I wanna run this project and I wanna restart it when my file changes. Like, you immediately know how to do that because it's the same everywhere. Um, and this kind of feeling of having to learn one tool and then being able to use all of the projects, like being able to con contribute to open source when you're moving jobs, whatever, like between personal projects that you haven't touched in two years, you know, like being able to learn this once and then use it everywhere is such an incredibly powerful tool. Like, people don't appreciate this until they've used a runtime or, or, or language which provides this to them. Like, you can go to any go developer and ask them if they would like. There, there's this, there's this saying in the Go ecosystem, um, that Go FMT is nobody's favorite, but, or, uh, wait, no, I don't remember what the, how the saying goes, but the saying essentially implies that the way that go FMT formats code, maybe not everybody likes, but everybody loves go F M T anyway, because it just makes everything look the same. And like, you can read your friend's code, your, your colleagues code, your new jobs code, the same way that you did your code from two years ago. And that's such an incredibly powerful feeling. especially if it's like well integrated into your IDE you clone a repository, open that repository, and like your testing panel on the left hand side just populates with all the tests, and you can click on them and run them. And if an assertion fails, it's like the standard output format that you're already familiar with. And it's, it's, it's a really great feeling. and if you don't believe me, just go try it out and, and then you will believe me, (laughs) [00:26:25] Jeremy: Yeah. No, I, I'm totally with you. I, I think it's interesting because with JavaScript in particular, it feels like the default in the community is the opposite, right? There's so many different ways. Uh, there are so many different build tools and testing frameworks and, formatters, and it's very different than, like you were mentioning, a go or a Rust that are more recent languages where they just include that, all Bundled in. Yeah. [00:26:57] Luca: Yeah, and I, I think you can see this as well in, in the time that average JavaScript developer spends configuring their tooling compared to a rest developer. Like if I write Rust, I write Rust, like all day, every day. and I spend maybe two, 3% of my time configuring Rust tooling like. Doing dependency imports, opening a new project, creating a format or config file, I don't know, deleting the build directory, stuff like that. Like that's, that's essentially what it means for me to configure my rest tooling. Whereas if you compare this to like a front-end JavaScript project, like you have to deal with making sure that your React version is compatible with your React on version, it's compatible with your next version is compatible with your ve version is compatible with your whatever version, right? this, this is all not automatic. Making sure that you use the right, like as, as a front end developer, you developer. You don't have just NPM installed, no. You have NPM installed, you have yarn installed, you have PNPM installed. You probably have like, Bun installed. And, and, and I don't know to use any of these, you need to have corepack enabled in Node and like you need to have all of their global bin directories symlinked into your or, or, or, uh, included in your path. And then if you install something and you wanna update it, you don't know, did I install it with yarn? Did I install it with N pNPM? Like this is, uh, significant complexity and you, you tend to spend a lot of time dealing with dependencies and dealing with package management and dealing with like tooling configuration, setting up esent, setting up prettier. and I, I think that like, especially Prettier, for example, really showed, was, was one of the first things in the JavaScript ecosystem, which was like, no, we're not gonna give you a config where you, that you can spend like six hours configuring, it's gonna be like seven options and here you go. And everybody used it because, Nobody likes configuring things. It turns out, um, and even though there's always the people that say, oh, well, I won't use your tool unless, like, we, we get this all the time. Like, I'm not gonna use Deno FMT because I can't, I don't know, remove the semicolons or, or use single quotes or change my tab width to 16. Right? Like, wait until all of your coworkers are gonna scream at you because you set the tab width to 16 and then see what they change it to. And then you'll see that it's actually the exact default that, everybody uses. So it'll, it'll take a couple more years. But I think we're also gonna get there, uh, like Node is starting to implement a, a test runner. and I, I think over time we're also gonna converge on, on, on, on like some standard build tools. Like I think ve, for example, is a great example of this, like, Doing a front end project nowadays. Um, like building new front end tooling that's not built on Vite Yeah. Don't like, Vite's it's become the standard and I think we're gonna see that in a lot more places. We should settle on what tools to use [00:29:52] Jeremy: Yeah, though I, I think it's, it's tricky, right? Because you have so many people with their existing projects. You have people who are starting new projects and they're just searching the internet for what they should use. So you're, you're gonna have people on web pack, you're gonna have people on Vite, I guess now there's gonna be Turbo pack, I think is another one that's [00:30:15] Luca: Mm-hmm. [00:30:16] Jeremy: There's, there's, there's all these different choices, right? And I, I think it's, it's hard to, to really settle on one, I guess, [00:30:26] Luca: Yeah, [00:30:27] Jeremy: uh, yeah. [00:30:27] Luca: like I, I, I think this is, this is in my personal opinion also failure of the Node Technical Steering committee, for the longest time to not decide that yes, we're going to bless this as the standard format for Node, and this is the standard package manager for Node. And they did, they sort of did, like, they, for example, node Blessed NPM as the standard, package manager for N for for node. But it didn't innovate on npm. Like no, the tech nodes, tech technical steering committee did not force NPM to innovate NPMs, a private company ultimately bought by GitHub and they had full control over how the NPM cli, um, evolved and nobody forced NPM to, to make sure that package install times are six times faster than they were. Three years ago, like nobody did that. so it didn't happen. And I think this is, this is really a failure of, of the, the, the, yeah, the no technical steering committee and also the wider JavaScript ecosystem of not being persistent enough with, with like focus on performance, focus on user experience, and, and focus on simplicity. Like things got so out of hand and I'm happy we're going in the right direction now, but, yeah, it was terrible for some time. (laughs) Node compatibility layer [00:31:41] Jeremy: I wanna talk a little bit about how we've been talking about Deno in the context of you just using Deno using its own standard library, but just recently last year you added a compatibility shim where people are able to use node libraries in Deno. [00:32:01] Luca: Mm-hmm. [00:32:01] Jeremy: And I wonder if you could talk to, like earlier you had mentioned that Deno has, a different permissions model. on the website it mentions that Deno's HTTP server is two times faster than node in a Hello World example. And I'm wondering what kind of benefits people will still get from Deno if they choose to use packages from Node. [00:32:27] Luca: Yeah, it's a great question. Um, so I think a, again, this is sort of a like, so just to clarify what we actually implemented, like what we have is we have support for you to import NPM packages. Um, so you can import any NPM package from NPM, from your type script or JavaScript ECMAScript module, um, that you have, you already have for your Deno code. Um, and we will under the hood, make sure that is installed somewhere in some directory globally. Like PNPM does. There's no local node modules folder you have to deal with. There's no package of Jason you have to deal with. Um, and there's no, uh, package. Jason, like versioning things you need to deal with. Like what you do is you do import cowsay from NPM colon cowsay at one, and that will import cowsay with like the semver tag one. Um, and it'll like do the sim resolution the same way node does, or the same way NPM does rather. And what you get from that is that essentially it gives you like this backdoor to a callout to all of the existing node code that Isri been written, right? Like you cannot expect that Deno developers, write like, I don't know. There was this time when Deno did not really have that many, third party modules yet. It was very early on, and I don't know the, you either, if you wanted to connect to Postgres and there was no Postgres driver available, then the solution was to write your own Postgres driver. And that is obviously not great. Um, (laughs) . So the better solution here is to let users for these packages where there's no Deno native or, or, or web native or standard native, um, package for this yet that is importable with url. Um, specifiers, you can import this from npm. Uh, so it's sort of this like backdoor into the existing NPM ecosystem. And we explicitly, for example, don't allow you to, create a package.json file or, import bare node specifiers because we don't, we, we want to stay standards compliant here. Um, but to make this work effectively, we need to give you this little back door. Um, and inside of this back door. All hell is like, or like everything is terrible inside there, right? Like inside there you can do bare specifiers and inside there you can like, uh, there's package.json and there's crazy node resolution and underscore underscore DIRNAME and common js. And like all of that stuff is supported inside of this backdoor to make all the NPM packages work. But on the outside it's exposed as this nice, ESM only, NPM specifiers. and the, the reason you would want to use this over, like just using node directly is because again, like you wanna use TypeScript, no config, like necessary. You want to use, you wanna have a formatter you wanna have a linter, you wanna have tooling that like does testing and benchmarking and compiling or whatever. All of that's built in. You wanna run this on the edge, like close to your users and like 30 different, 35 different, uh, points of presence. Um, it's like, Okay, push it to your git repository. Go to this website, click a button two times, and it's running in 35 data centers. like this is, this is the kind of ex like developer experience that you can, you do not get. You, I will argue that you cannot get with Node right now. Like even if you're using something like ts-node, it is not possible to get the same level of developer experience that you do with Deno. And the, the, the same like speed at which you can iterate, iterate on your projects, like create new projects, iterate on them is like incredibly fast in Deno. Like, I can open a, a, a folder on my computer, create a single file, may not ts, put some code in there and then call Deno Run may not. And that's it. Like I don't, I did not need to do NPM install I did not need to do NPM init -y and remove the license and version fields and from, from the generated package.json and like set private to true and whatever else, right? It just all works out of the box. And I think that's, that's what a lot of people come to deno for and, and then ultimately stay for. And also, yeah, standards compliance. So, um, things you build in Deno now are gonna work in five, 10 years, with no hassle. Node shims and testing [00:36:39] Jeremy: And so with this compatibility layer or this, this shim, is it where the node code is calling out to node APIs and you're replacing those with Deno compatible equivalents? [00:36:54] Luca: Yeah, exactly. Like for example, we have a shim in place that shims out the node crypto API on top of the web crypto api. Like sort of, some, some people may be familiar with this in the form of, um, Browserify shims. if anybody still remembers those, it's essentially. , your front end tooling, you were able to import from like node crypto in your front end projects and then behind the scenes your web packs or your browser replies or whatever would take that import from node crypto and would replace it with like the shim that was essentially exposed the same APIs node crypto, but under the hood, wasn't implemented with native calls, but was implemented on top of web crypto, or implemented in user land even. And Deno does something similar. there's a couple edge cases of APIs that there's, where, where we do not expose the underlying thing that we shim to, to end users, outside of the node shim. So like there's some, some APIs that I don't know if I have a good example, like node nextTick for example. Um, like to properly be able to shim node nextTick, you need to like implement this within the event loop in the runtime. and. , you don't need this in Deno, because Deno, you use the web standard queueMicrotask to, to do this kind of thing. but to be able to shim it correctly and run node applications correctly, we need to have this sort of like backdoor into some ugly APIs, um, which, which natively integrate in the runtime, but, yeah, like allow, allow this node code to run. [00:38:21] Jeremy: A, anytime you're replacing a component with a, a shim, I think there's concerns about additional bugs or changes in behavior that can be introduced. Is that something that you're seeing and, and how are you accounting for that? [00:38:38] Luca: Yeah, that's, that's an excellent question. So this is actually a, a great concern that we have all the time. And it's not just even introducing bugs, sometimes it's removing bugs. Like sometimes there's bugs in the node standard library which are there, and people are relying on these bugs to be there for the applications to function correctly. And we've seen this a lot, and then we implement this and we implement from scratch and we don't make that same bug. And then the test fails or then the application fails. So what we do is, um, we actually run node's test suite against Deno's Shim layer. So Node has a very extensive test suite for its own standard library, and we can run this suite against, against our shims to find things like this. And there's still edge cases, obviously, which node, like there was, maybe there's a bug which node was not even aware of existing. Um, where maybe this, like it's is, it's now standard, it's now like intended behavior because somebody relies on it, right? Like the second somebody relies on, on some non-standard or some buggy behavior, it becomes intended. Um, but maybe there was no test that explicitly tests for this behavior. Um, so in that case we'll add our own tests to, to ensure that. But overall we can already catch a lot of these by just testing, against, against node's tests. And then the other thing is we run a lot of real code, like we'll try run Prisma and we'll try run Vite and we'll try run NextJS and we'll try run like, I don't know, a bunch of other things that people throw at us and, check that they work and they work and there's no bugs. Then we did our job well and our shims are implemented correctly. Um, and then there's obviously always the edge cases where somebody did something absolutely crazy that nobody thought possible. and then they'll open an issue on the Deno repo and we scratch our heads for three days and then we'll fix it. And then in the next release there'll be a new bug that we added to make the compatibility with node better. so yeah, but I, yeah. Running tests is the, is the main thing running nodes test. Performance should be equal or better [00:40:32] Jeremy: Are there performance implications? If someone is running an Express App or an NextJS app in Deno, will they get any benefits from the Deno runtime and performance? [00:40:45] Luca: Yeah. It's actually, there is performance implications and they're usually. The opposite of what people think they are. Like, usually when you think of performance implications, it's always a negative thing, right? It's always okay. Like you, it's like a compromise. like the shim layer must be slower than the real node, right? It's not like we can run express faster than node can run, express. and obviously not everything is faster in Deno than it is in node, and not everything is faster in node than it is in Deno. It's dependent on the api, dependent on, on what each team decided to optimize. Um, and this also extends to other run times. Like you can always cherry pick results, like, I don't know, um, to, to make your runtime look faster in certain benchmarks. but overall, what really matters is that you do not like, the first important step for for good node compatibility is to make sure that if somebody runs your code or runs their node code in Deno or your other run type or whatever, It performs at least the same. and then anything on top of that great cherry on top. Perfect. but make sure the baselines is at least the same. And I think, yeah, we have very few APIs where we behave, where we, where, where like there's a significant performance degradation in Deno compared to Node. Um, and like we're actively working on these things. like Deno is not a, a, a project that's done, right? Like we have, I think at this point, like 15 or 16 or 17 engineers working on Deno, spanning across all of our different projects. And like, we have a whole team that's dedicated to performance, um, and a whole team that's dedicated node compatibility. so like these things get addressed and, and we make patch releases every week and a minor release every four weeks. so yeah, it's, it's not a standstill. It's, uh, constantly improving. What should go into the standard library? [00:42:27] Jeremy: Uh, something that kind of makes Deno stand out as it's standard library. There's a lot more in there than there is in in the node one. [00:42:38] Luca: Mm-hmm. [00:42:39] Jeremy: Uh, I wonder if you could speak to how you make decisions on what should go into it. [00:42:46] Luca: Yeah, so early on it was easier. Early on, the, the decision making process was essentially, is this something that a top 100 or top 1000 NPM library implements? And if it is, let's include it. and the decision making is still short of based on that. But right now we've already implemented most of the low hanging fruit. So things that we implement now are, have, have discussion around them whether we should implement them. And we have a process where, well we have a whole team of engineers on our side and we also have community members that, that will review prs and, and, and make comments. Open issues and, and review those issues, to sort of discuss the pros and cons of adding any certain new api. And sometimes it's also that somebody opens an issue that's like, I want, for example, I want an API to, to concatenate two unit data arrays together, which is something you can really easily do node with buffer dot con cat, like the scary buffer thing. and there's no standards way of doing that right now. So we have to have a little utility function that does that. But in parallel, we're thinking about, okay, how do we propose, an addition to the web standards now that makes it easy to concatenate iterates in the web standards, right? yeah, there's a lot to it. Um, but it's, it's really, um, it's all open, like all of our, all of our discussions for, for, additions to the standard library and things like that. It's all, all, uh, public on GitHub and the GitHub issues and GitHub discussions and GitHub prs. Um, so yeah, that's, that's where we do that. [00:44:18] Jeremy: Yeah, cuz to give an example, I was a little surprised to see that there is support for markdown front matter built into the standard library. But when you describe it as we look at the top a hundred thousand packages, are people looking at markdown? Are they looking at front matter? I, I'm sure there's a fair amount that are so that that makes sense. [00:44:41] Luca: Yeah, like it sometimes, like that one specifically was driven by, like, our team was just building a lot of like little blog pages and things like that. And every time it was either you roll your own front matter part or you look for one, which has like a subtle bug here and the other one has a subtle bug there and really not satisfactory with any of them. So, we, we roll that into the standard library. We add good test coverage for it good, add good documentation for it, and then it's like just a resource that people can rely on. Um, and you don't, you then don't have to make the choice of like, do I use this library to do my front meta parsing or the other library? No, you just use the one that's in the standard library. It's, it's also part of this like user experience thing, right? Like it's just a much nicer user experience, not having to make a choice, about stuff like that. Like completely inconsequential stuff. Like which library do we use to do front matter parsing? (laughs) [00:45:32] Jeremy: yeah. I mean, I think when, when that stuff is not there, then I think the temptation is to go, okay, let me see what node modules there are that will let me parse the front matter. Right. And then it, it sounds like probably ideally you want people to lean more on what's either in the standard library or what's native to the Deno ecosystem. Yeah. [00:46:00] Luca: Yeah. Like the, the, one of the big benefits is that the Deno Standard Library is implemented on top of web standards, right? Like it's, it's implemented on top of these standard APIs. so for example, there's node front matter libraries which do not run in the browser because the browser does not have the buffer global. maybe it's a nice library to do front matter pricing with, but. , you choose it and then three days later you decide that actually this code also needs to run in the browser, and then you need to go switch your front matter library. Um, so, so those are also kind of reasons why we may include something in Strand Library, like maybe there's even really good module already to do something. Um, but if there's certain reliance on specific node features that, um, we would like that library to also be compatible with, with, with web standards, we'll, uh, we might include in the standard library, like for example, YAML Parser, um, or the YAML Parser in the standard library is, is a fork of, uh, of the node YAML module. and it's, it's essentially that, but cleaned up and, and made to use more standard APIs rather than, um, node built-ins. [00:47:00] Jeremy: Yeah, it kind of reminds me a little bit of when you're writing a front end application, sometimes you'll use node packages to do certain things and they won't work unless you have a compatibility shim where the browser can make use of certain node APIs. And if you use the APIs that are built into the browser already, then you won't, you won't need to deal with that sort of thing. [00:47:26] Luca: Yeah. Also like less Bundled size, right? Like if you don't have to shim that, that's less, less code you have to ship to the client. WebAssembly use cases [00:47:33] Jeremy: Another thing I've seen with Deno is it supports running web assembly. [00:47:40] Luca: Mm-hmm. [00:47:40] Jeremy: So you can export functions and call them from type script. I was curious if you've seen practical uses of this in production within the context of Deno. [00:47:53] Luca: Yeah. there's actually a Bunch of, of really practical use cases, so probably the most executed bit of web assembly inside of Deno right now is actually yes, build like, yes, build has a web assembly, build like yeses. Build is something that's written and go. You have the choice of either running. Um, natively in machine code as, as like an ELF process on, on Linux or on on Windows or whatever. Or you can use the web assembly build and then it runs in web assembly. And the web assembly build is maybe 50% slower than the, uh, native build, but that is still significantly faster than roll up or, or, or, or I don't know, whatever else people use nowadays to do JavaScript Bun, I don't know. I, I just use es build always, um, So, um, for example, the Deno website, is running on Deno Deploy. And Deno Deploy does not allow you to run Subprocesses because it's, it's like this edge run time, which, uh, has certain security permissions that it's, that are not granted, one of them being sub-processes. So it needs to execute ES build. And the way it executes es build is by running them inside a web assembly. Um, because web assembly is secure, web assembly is, is something which is part of the JavaScript sandbox. It's inside the JavaScript sandbox. It doesn't poke any holes out. Um, so it's, it's able to run within, within like very strict security context. . Um, and then other examples are, I don't know, you want to have a HTML sanitizer, which is actually built on the real HTML par in a browser. we, we have an hdml sanitizer called com or, uh, ammonia, I don't remember. There's, there's an HTML sanitizer library on denoland slash x, which is built on the html parser from Firefox. Uh, which like ensures essentially that your html, like if you do HTML sanitization, you need to make sure your HTML par is correct, because if it's not, you might like, your browser might parse some HTML one way and your sanitizer pauses it another way and then it doesn't sanitize everything correctly. Um, so there's this like the Firefox HTML parser compiled to web assembly. Um, you can use that to. HTML sanitization, or the Deno documentation generation tool, for example. Uh, Deno Doc, there's a web assembly built for it that allows you to programmatically, like generate documentation for, for your type script modules. Um, yeah, and, and also like, you know, deno fmt is available as a WebAssembly module for programmatic access and a Bunch of other internal Deno, programs as well. Like, or, uh, like components, not programs. [00:50:20] Jeremy: What are some of the current limitations of web assembly and Deno for, for example, from web assembly, can I make HTTP requests? Can I read files? That sort of thing. [00:50:34] Luca: Mm-hmm. . Yeah. So web assembly, like when you spawn as web assembly, um, they're called instances, WebAssembly instances. It runs inside of the same vm, like the same, V8 isolate is what they're called, but. it does not have it, it's like a completely fresh sandbox, sort of, in the sense that I told you that between a runtime and like an engine essentially implements no IO calls, right? And a runtime does, like a runtime, pokes holds into the, the, the engine. web assembly by default works the same way that there is no holes poked into its sandbox. So you have to explicitly poke some holes. Uh, if you want to do HTTP calls, for example, when, when you create web assembly instance, it gives you, or you can give it something called imports, uh, which are essentially JavaScript function bindings, which you can call from within the web assembly. And you can use those function bindings to do anything you can from JavaScript. You just have to pass them through explicitly. and. . Yeah. Depending on how you write your web assembly, like if you write it in Rust, for example, the tooling is very nice and you can just call some JavaScript code from your Rust, and then the build system will automatically make sure that the right function bindings are passed through with the right names. And like, you don't have to deal with anything. and if you're writing go, it's slightly more complicated. And if you're writing like raw web assembly, like, like the web assembly, text format and compiling that to a binary, then like you have to do everything yourself. Right? It's, it's sort of the difference between writing C and writing JavaScript. Like, yeah. What level of abstraction do you want? It's definitely possible though, and that's for limitations. it, the same limitations as, as existing browsers apply. like the web assembly support in Deno is equivalent to the web assembly support in Chrome. so you can do, uh, many things like multi-threading and, and stuff like that already. but especially around, shared mutable memory, um, and having access to that memory from JavaScript. That's something which is a real difficulty with web assembly right now. yeah, growing web assembly memory is also rather difficult right now. There's, there's a, there's a couple inherent limitations right now with web assembly itself. Um, but those, those will be worked out over time. And, and Deno is like very up to date with the version of, of the standard, it, it implements, um, through v8. Like we're, we're, we're up to date with Chrome Beta essentially all the time. So, um, yeah. Any, anything you see in, in, in Chrome beta is gonna be in Deno already. Deno Deploy [00:52:58] Jeremy: So you talked a little bit about this before, the Deno team, they have their own, hosting. Platform called Deno Deploy. So I wonder if you could explain what that is. [00:53:12] Luca: Yeah, so Deno has this really nice, this really nice concept of permissions which allow you to, sorry, I'm gonna start somewhere slightly, slightly unrelated. Maybe it sounds like it's unrelated, but you'll see in a second. It's not unrelated. Um, Deno has this really nice permission system which allows you to sandbox Deno programs to only allow them to do certain operations. For example, in Deno, by default, if you try to open a file, it'll air out and say you don't have read permissions to read this file. And then what you do is you specify dash, dash allow read um, maybe you have to give it. they can either specify, allow, read, and then it'll grant to read access to the entire file system. Or you can explicitly specify files or folders or, any number of things. Same goes for right permissions, same goes for network permissions. Um, same goes for running subprocesses, all these kind of things. And by limiting your permissions just a little bit. Like, for example, by just disabling sub-processes and foreign function interface, but allowing everything else, allowing reeds and allowing network access and all that kind of stuff. we can run Deno programs in a way that is significantly more cost effective to you as the end user than, and, and like we can cold start them much faster than, like you may be able to with a, with a more conventional container based, uh, system. So what, what do you, what Deno Deploy is, is a way to run JavaScript or Deno Code, on our data centers all across the world with very little latency. like you can write some JavaScript code which execute, which serves HTTP requests deploy that to our platform, and then we'll make sure to spin that code up all across the world and have your users be able to access it through some URL or, or, or some, um, custom domain or something like that. and this is some, this is very similar to CloudFlare workers, for example. Um, and it's like Netlify Edge functions is built on top of Deno Deploy. Like Netlify Edge functions is implemented on top of Deno Deploy, um, through our sub hosting product. yeah, essentially Deno Deploy is, is, um, yeah, a cloud hosting service for JavaScript, um, which allows you to execute arbitrary JavaScript. and there there's a couple, like different directions we're going there. One is like more end user focused, where like you link your GitHub repository and. Like, we'll, we'll have a nice experience like you do with Netlify and Versace, that word like your commits automatically get deployed and you get preview deployments and all that kind of thing. for your backend code though, rather than for your front end websites. Although you could also write front-end websites and you know, obviously, and the other direction is more like business focused. Like you're writing a SaaS application and you want to allow the user to customize, the check like you're writing a SaaS application that provides users with the ability to write their own online store. Um, and you want to give them some ability to customize the checkout experience in some way. So you give them a little like text editor that they can type some JavaScript into. And then when, when your SaaS application needs to hit this code path, it sends a request to us with the code, we'll execute that code for you in a secure way. In a secure sandbox. You can like tell us you, this code only has access to like my API server and no other networks to like prevent data exfiltration, for example. and then you do, you can have all this like super customizable, code in inside of your, your SaaS application without having to deal with any of the operational complexities of scaling arbitrary code execution, or even just doing arbitrary code execution, right? Like it's, this is a very difficult problem and give it to someone else and we deal with it and you just get the benefits. yeah, that's Deno Deploy, and it's built by the same team that builds the Deno cli. So, um, all the, all of your favorite, like Deno cli, or, or Deno APIs are available in there. It's just as web standard is Deno, like you have fetch available, you have blob available, you have web crypto available, that kind of thing. yeah. Running code in V8 isolates [00:56:58] Jeremy: So when someone ships you their, their code and you run it, you mentioned that the, the cold start time is very low. Um, how, how is the code being run? Are people getting their own process? It sounds like it's not, uh, using containers. I wonder if you could explain a little bit about how that works. [00:57:20] Luca: Yeah, yeah, I can, I can give a high level overview of how it works. So, the way it works is that we essentially have a pool of, of Deno processes ready. Well, it's not quite Deno processes, it's not the same Deno CLI that you download. It's like a modified version of the Deno CLI based on the same infrastructure, that we have spun up across all of our different regions across the world, uh, across all of our different data centers. And then when we get a request, we'll route that request, um, the first time we get request for that, that we call them deployments, that like code, right? We'll take one of these idle Deno processes and will assign that code to run in that process, and then that process can go serve the requests. and these process, they're, they're, they're isolated and they're, you. it's essentially a V8 isolate. Um, and it's a very, very slim, it's like, it's a much, much, much slimmer version of the Deno cli essentially. Uh, which the only thing it can do is JavaScript execution and like, it can't even execute type script, for example, like type script is we pre-process it up front to make the the cold start faster. and then what we do is if you don't get a request for some amount of. , we'll, uh, spin down that, um, that isolate and, uh, we'll spin up a new idle one in its place. And then, um, if you get another request, I don't know, an hour later for that same deployment, we'll assign it to a new isolate. And yeah, that's a cold start, right? Uh, if you have an isolate which receives, or a, a deployment rather, which receives a Bunch of traffic, like let's say you receive a hundred requests per second, we can send a Bunch of that traffic to the same isolate. Um, and we'll make sure that if, that one isolate isn't able to handle that load, we'll spin it out over multiple isolates and we'll, we'll sort of load balance for you. Um, and we'll make sure to always send to the, to the point of present that's closest to, to the user making the request. So they get very minimal latency. and they get we, we've these like layers of load balancing in place and, and, and. I'm glossing over a Bunch of like security related things here about how these, these processes are actually isolated and how we monitor to ensure that you don't break out of these processes. And for example, Deno Deploy does, it looks like you have a file system cuz you can read files from the file system. But in reality, Deno Deploy does not have a file system. Like the file system is a global virtual file system. which is, is, uh, yeah, implemented completely differently than it is in Deno cli. But as an end user you don't have to care about that because the only thing you care about is that it has the exact same API as the Deno cli and you can run your code locally and if it works there, it's also gonna work in deploy. yeah, so that's, that's, that's kind of. High level of Deno Deploy. If, if any of this sounds interesting to anyone, by the way, uh, we're like very actively hiring on, on Deno Deploy. I happen to be the, the tech lead for, for a Deno Deploy product. So I'm, I'm always looking for engineers, to, to join our ranks and, and build cool distributed systems. Deno.com/jobs. [01:00:15] Jeremy: for people who aren't familiar with the isolates, are these each run in their own processes, or do you have a single process and that has a whole Bunch of isolates inside it? [01:00:28] Luca: in, in the general case, you can say that we run, uh, one isolate per process. but there's many asterisks on that. Um, because, it's, it's very complicated. I'll just say it's very complicated. Uh, in, in the general case though, it's, it's one isolate per process. Yeah. Configuring permissions [01:00:45] Jeremy: And then you touched a little bit on the permissions system. Like you gave the example of somebody could have a website where they let their users give them code to execute. how does it look in terms of specifying what permissions people have? Like, is that a configuration file? Are those flags you pass in? What, what does that look? [01:01:08] Luca: Yeah. So, so that product is called sub hosting. It's, um, slightly different from our end user platform. Um, it's essentially a service that allows you to, like, you email us, well, we'll send you a, um, onboard you, and then what you can do is you can send HTTP requests to a certain end point with a, authentication token and. a reference to some code to execute. And then what we'll do is, we'll, um, when we receive that HTTP request, we'll fetch the code, it's spin up and isolate, execute the code. execute the code. We serve the request, return you the response, um, and then we'll pipe logs to you and, and stuff like that. and the, and, and part of that is also when we, when we pull the, um, the, the code for to spin up the isolate, that code doesn't just include the code that we're executing, but also includes things like permissions, and, and various other, we call this isolate configuration. Um, you can inspect, this is all public. we have public docs for this at Deno.com/subhosting. I think. Yes, Deno.com/subhosting. [01:02:08] Jeremy: And is that built on top of something that's a part of the public Deno project, the open source part? Or is this specific to this sub hosting

Join the four Developer Advocates as we go around the table and share what we're most excited about in Utah. Topics 00:00 Welcome/introductions 02:16 Workspace Builder 03:41 RPA on PDIs 05:48 Dark theme 08:06 Script editor enhancements 09:32 ERP customization mining 13:18 Automation Center 15:20 Flow updates 18:28 Next Experience updates 21:29 Table builder 23:17 REST step updates 25:33 ECMAScript default for new apps 28:40 Mobile multi-instance switching 30:44 Lightning round 33:30 Outro Links Release notes Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

Join the four Developer Advocates as we go around the table and share what we're most excited about in Utah. Topics 00:00 Welcome/introductions 02:16 Workspace Builder 03:41 RPA on PDIs 05:48 Dark theme 08:06 Script editor enhancements 09:32 ERP customization mining 13:18 Automation Center 15:20 Flow updates 18:28 Next Experience updates 21:29 Table builder 23:17 REST step updates 25:33 ECMAScript default for new apps 28:40 Mobile multi-instance switching 30:44 Lightning round 33:30 Outro Links Release notes Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

話したネタ denoの話 Bun first impressions Node.js、Deno、Bunとは何か？ JavaScriptランタイムとは何か？ サーバーサイドJavaScript expressを利用してWebサーバーを立てるコードは、Node.js以外でも動くのか？ ECMAScript と ランタイム との関係は？ TC39 Node.js はどんな経緯で生まれてきた？ Rubyを書くタイミングと、JavaScriptを書くタイミングでのコンテキストスイッチ netv8 イベントループモデルとは何か？ ブロッキング処理、for文やJSON.parse() なぜ、Node.jsはここまで人気が出たのか？ V8(JavaScriptエンジン)とは何か？ JavaScriptCore Edge Workerとの相性の良さ JITコンパイラ Denoはどういう背景で生まれてきているのか？ モジュールを取り巻く課題 JSConf JP 訂正 冒頭で第81回と話しておりますが、82回の誤りです。 番組のスポンサーD.Node採用募集ページはこちら

One of the biggest announcements for developers in our Tokyo release is the update to our ECMAScript engine. Today's guest gives some inside information behind this update. Topics 00:00 Welcome and introduction 05:57 Overview of ECMAScript 2021 09:04 Is this THE ECMAScript 2021? 11:02 Suggesting enhancements 12:35 The global scope 15:42 Where it's enabled 16:42 The roadmap 21:34 Contact information 22:16 Outro Links LinkedIn JavaScript engine feature support Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

One of the biggest announcements for developers in our Tokyo release is the update to our ECMAScript engine. Today's guest gives some inside information behind this update. Topics 00:00 Welcome and introduction 05:57 Overview of ECMAScript 2021 09:04 Is this THE ECMAScript 2021? 11:02 Suggesting enhancements 12:35 The global scope 15:42 Where it's enabled 16:42 The roadmap 21:34 Contact information 22:16 Outro Links LinkedIn JavaScript engine feature support Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

Steve, Dan and A.J talk with Nick Hehr and Peter Hoddie about using JavScript with IoT devices. They cover a wide range of topics, including the XS JavaScript Engine, the only complete ECMAScript 2018 engine optimized for embedded devices (created by Moddable), and even get into the nitty gritty of how it is built and how it works. They also cover TC53 - the standards committee for JS in embedded systems, a committee that Nick and Peter are part of. In picks, they get into a great discussion on home security systems and their various security issue, and of course, Steve brings the great dad jokes. Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs Links TC53 Resuscitating IoT with JavaScript - Peter Hoddie & Lizzie Prader, Moddable - YouTubeECMA-419: The ECMAScript Embedded Systems API and J5e - Donovan Buck, BrandExtract - YouTube HipsterBrown Moddable Twitter: @hipsterbrown Twitter: @phoddie Picks AJ- GitHub - BeyondCodeBootcamp/jsdoc-typescript-starter AJ- Typing without Transpilation AJ- Eyeglasses Online | Eyewear for Everyone™ | Zenni Optical AJ- Amazon.com. Spend less. Smile more. AJ- Oakley MX L Frame Adult Tear-Off Off-Road/Dirt Bike Motorcycle Eyewear Accessories Nick -Microcenter Nick- Abode Home Security - #1 DIY Wireless Home Security Solution Nick-  Build With Matter | Smart Home Device Solution Peter- The Extensible Web Manifesto Peter- Fanny Mendelssohn - Wikipedia Steve-  Introducing multitasking to Arduino | Arduino Blog Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

Steve, Dan and A.J talk with Nick Hehr and Peter Hoddie about using JavScript with IoT devices. They cover a wide range of topics, including the XS JavaScript Engine, the only complete ECMAScript 2018 engine optimized for embedded devices (created by Moddable), and even get into the nitty gritty of how it is built and how it works. They also cover TC53 - the standards committee for JS in embedded systems, a committee that Nick and Peter are part of. In picks, they get into a great discussion on home security systems and their various security issue, and of course, Steve brings the great dad jokes. Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs Links TC53 Resuscitating IoT with JavaScript - Peter Hoddie & Lizzie Prader, Moddable - YouTubeECMA-419: The ECMAScript Embedded Systems API and J5e - Donovan Buck, BrandExtract - YouTube HipsterBrown Moddable Twitter: @hipsterbrown Twitter: @phoddie Picks AJ- GitHub - BeyondCodeBootcamp/jsdoc-typescript-starter AJ- Typing without Transpilation AJ- Eyeglasses Online | Eyewear for Everyone™ | Zenni Optical AJ- Amazon.com. Spend less. Smile more. AJ- Oakley MX L Frame Adult Tear-Off Off-Road/Dirt Bike Motorcycle Eyewear Accessories Nick -Microcenter Nick- Abode Home Security - #1 DIY Wireless Home Security Solution Nick-  Build With Matter | Smart Home Device Solution Peter- The Extensible Web Manifesto Peter- Fanny Mendelssohn - Wikipedia Steve-  Introducing multitasking to Arduino | Arduino Blog

The Tokyo release is here and it's time to find out what our developer advocates think are their favorite features – this time on Break Point. Topics 00:00 Welcome and introductions 02:00 App Engine Management Center 04:18 Upgrade center/Upgrade plans 06:38 ECMAScript 2021 09:04 App template governance 10:58 Formula builder (with low-code editorial) 14:55 OAuth for non-admin users 16:49 Document Intelligence 20:13 Next Experience 22:45 Translated notifications 25:30 Honorable mentions 30:25 Words of wisdom 33:09 Outro Links TechNow Ep 94: Take a look at the Tokyo release Now Platform features Tokyo Content Schedule Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

The Tokyo release is here and it's time to find out what our developer advocates think are their favorite features – this time on Break Point. Topics 00:00 Welcome and introductions 02:00 App Engine Management Center 04:18 Upgrade center/Upgrade plans 06:38 ECMAScript 2021 09:04 App template governance 10:58 Formula builder (with low-code editorial) 14:55 OAuth for non-admin users 16:49 Document Intelligence 20:13 Next Experience 22:45 Translated notifications 25:30 Honorable mentions 30:25 Words of wisdom 33:09 Outro Links TechNow Ep 94: Take a look at the Tokyo release Now Platform features Tokyo Content Schedule Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

A mai adásban több témát érintünk. Szó lesz url-hijackingről, ECMAScript 2022 specifikációról, és miről másról, mint IT cégekről.  Résztvevők: Pisti Róka Újdonságok DevTools Chrome 103-ban: https://developer.chrome.com/blog/new-in-devtools-103/#color PyPi Package: https://www.bleepingcomputer.com/news/security/pypi-package-keep-mistakenly-included-a-password-stealer/ ECMAScript2022 https://dev.to/jasmin/whats-new-in-es2022-1de6 https://tc39.es/ecma262/ Legjobb IT cégek https://www.computerworld.com/article/3665091/now-open-for-entries-best-places-to-work-in-it-2022.html Tech cégek lassítanak https://www.bloomberg.com/news/articles/2022-07-12/google-ceo-says-company-plans-to-slow-hiring-for-rest-of-year Hallgasd kedvenc lejátszódban, ne csak a legfrissebb részt! Google Podcasts - https://podcasts.google.com/feed/aHR0cHM6Ly93d3cuaXZvb3guY29tL2VuL2RldnRhbGVzLXBvZGNhc3RfZmdfZjE1OTg1OTdfZmlsdHJvXzEueG1s Apple Podcasts - https://podcasts.apple.com/hu/podcast/devtales-podcast/id1386667284?mt=2 CastBox - https://castbox.fm/channel/DevTales-Podcast-id1295470 Pocket Casts - https://pca.st/podcast/5a10e180-5077-0136-fa7c-0fe84b59566dSpotify - https://open.spotify.com/show/4fS3YtJknqn1gSKa4HqKAt YouTube - https://www.youtube.com/channel/UC5nbDGKvuSK9NwOIJOiiwnARSS - https://devtales.shiwaforce.com/feed/podcast Facebook - https://www.facebook.com/groups/devtales Twitter - https://twitter.com/_devtales Slack - https://devtalespodcast.slack.com Email - devtales@shiwaforce.com fotó forrás: https://javascript.plainenglish.io/

Today we chat with Thomas Randolph from GitLab, to discuss his Top 10 list of the upcoming TC39 proposals. The list… Temporal Proposal Import Assertions JSON Modules Built-In Modules Observable Proposal Partial Application UUID Pipeline Operator Module Blocks Emitter Proposal +1 Records and Tuples +2 Reverse and Sort Methods on Arrays Sponsors Top End Devs (https://topenddevs.com/) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Twitter: Thomas Randolph ( @rockerest ) (https://twitter.com/rockerest) JSJ 425: The Evolution of JavaScript (https://javascriptjabber.com/jsj-425-the-evolution-of-javascript) Temporal (https://tc39.es/proposal-temporal/docs/) import assertions (https://tc39.es/proposal-import-assertions/) JSON modules (https://tc39.es/proposal-json-modules/) The TC39 Process (https://tc39.es/process-document/) Observable (https://tc39.es/proposal-observable/) Partial Application for ECMAScript (https://tc39.es/proposal-partial-application/) ES pipe operator (2021) (https://tc39.es/proposal-pipeline-operator/) JavaScript Module Blocks (https://tc39.es/proposal-js-module-blocks/) Record & Tuple (https://tc39.es/proposal-record-tuple/) ECMAScript proposal "Change Array by copy": four new non-destructive Array methods (https://2ality.com/2022/04/change-array-by-copy.html) GitHub: tc39/proposals (https://github.com/tc39/proposals) JavaScript Jabber 19 April 2022 (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas O. Randolph (https://rdl.ph/) Picks Charles - The Last Battle (https://www.audible.com/pd/The-Last-Battle-Audiobook/B002UZJF22) Charles - GamePigeon (https://apps.apple.com/us/app/gamepigeon/id1124197642) Dan - Star Trek: Picard (https://www.paramountplus.com/shows/star-trek-picard/) Dan - 103 Early Hints Dan - War in Ukraine Steve - Dad Jokes Steve - Rescinded mask mandates for travel Thomas - My notes to this episode (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas - The Design of Everyday Things by Don Norman (https://amzn.to/3Nifiw8) Thomas - What is Reactive Programming by Kevin Webber (https://blog.redelastic.com/what-is-reactive-programming-bc9fa7f4a7fc) Thomas - War in Ukraine Special Guest: Thomas Randolph.

Today we chat with Thomas Randolph from GitLab, to discuss his Top 10 list of the upcoming TC39 proposals. The list… Temporal Proposal Import Assertions JSON Modules Built-In Modules Observable Proposal Partial Application UUID Pipeline Operator Module Blocks Emitter Proposal +1 Records and Tuples +2 Reverse and Sort Methods on Arrays Sponsors Top End Devs (https://topenddevs.com/) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Twitter: Thomas Randolph ( @rockerest ) (https://twitter.com/rockerest) JSJ 425: The Evolution of JavaScript (https://javascriptjabber.com/jsj-425-the-evolution-of-javascript) Temporal (https://tc39.es/proposal-temporal/docs/) import assertions (https://tc39.es/proposal-import-assertions/) JSON modules (https://tc39.es/proposal-json-modules/) The TC39 Process (https://tc39.es/process-document/) Observable (https://tc39.es/proposal-observable/) Partial Application for ECMAScript (https://tc39.es/proposal-partial-application/) ES pipe operator (2021) (https://tc39.es/proposal-pipeline-operator/) JavaScript Module Blocks (https://tc39.es/proposal-js-module-blocks/) Record & Tuple (https://tc39.es/proposal-record-tuple/) ECMAScript proposal "Change Array by copy": four new non-destructive Array methods (https://2ality.com/2022/04/change-array-by-copy.html) GitHub: tc39/proposals (https://github.com/tc39/proposals) JavaScript Jabber 19 April 2022 (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas O. Randolph (https://rdl.ph/) Picks Charles - The Last Battle (https://www.audible.com/pd/The-Last-Battle-Audiobook/B002UZJF22) Charles - GamePigeon (https://apps.apple.com/us/app/gamepigeon/id1124197642) Dan - Star Trek: Picard (https://www.paramountplus.com/shows/star-trek-picard/) Dan - 103 Early Hints Dan - War in Ukraine Steve - Dad Jokes Steve - Rescinded mask mandates for travel Thomas - My notes to this episode (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas - The Design of Everyday Things by Don Norman (https://amzn.to/3Nifiw8) Thomas - What is Reactive Programming by Kevin Webber (https://blog.redelastic.com/what-is-reactive-programming-bc9fa7f4a7fc) Thomas - War in Ukraine Special Guest: Thomas Randolph.

What's at Stake in the Game of Civilization? We explore how technologies of intelligent voluntary cooperation can help us navigate the traps. Cryptocommerce enables decentralized, secure cooperation across humans – and AIs.Mark S. Miller is the chief scientist of Agoric, a pioneer of agoric (market-based secure distributed) computing and smart contracts, the main designer of the E and Dr. SES distributed persistent object-capability programming languages, inventor of Miller Columns, an architect of the Xanadu hypertext publishing system, a representative to the ECMAScript committee, a former Google research scientist, and a senior fellow of the Foresight Institute.Christine Peterson is cofounder and senior fellow at Foresight Institute. She writes and lectures to general audiences on a wide variety of topics including nanotechnology, longevity, and computer security.  Allison Duettmann is the president and CEO of Foresight Institute. She leads Foresight's longevity, molecular machines, neurotechnology, computing, and space programs, and shares their results with the public.Session summary: M. Miller, C. Peterson, A, Duettman: What's at Stake in the Game? | Gaming the Future Ch. 1,2 - Foresight InstituteThe Foresight Institute is a research organization and non-profit that supports the beneficial development of high-impact technologies. Since our founding in 1987 on a vision of guiding powerful technologies, we have continued to evolve into a many-armed organization that focuses on several fields of science and technology that are too ambitious for legacy institutions to support.Allison Duettmann is the president and CEO of Foresight Institute. She directs the Intelligent Cooperation, Molecular Machines, Biotech & Health Extension, Neurotech, and Space Programs, Fellowships, Prizes, and Tech Trees, and shares this work with the public. She founded Existentialhope.com, co-edited Superintelligence: Coordination & Strategy, co-authored Gaming the Future, and co-initiated The Longevity Prize. Apply to Foresight's virtual salons and in person workshops here!We are entirely funded by your donations. If you enjoy what we do please consider donating through our donation page.Visit our website for more content, or join us here:TwitterFacebookLinkedInEvery word ever spoken on this podcast is now AI-searchable using Fathom.fm, a search engine for podcasts.  Hosted on Acast. See acast.com/privacy for more information.

Today we chat with Thomas Randolph from GitLab, to discuss his Top 10 list of the upcoming TC39 proposals. The list… Temporal Proposal Import Assertions JSON Modules Built-In Modules Observable Proposal Partial Application UUID Pipeline Operator Module Blocks Emitter Proposal +1 Records and Tuples +2 Reverse and Sort Methods on Arrays Sponsors Top End Devs (https://topenddevs.com/) Raygun | Click here to get started on your free 14-day trial (https://raygun.com/?utm_medium=podcast&utm_source=jsjabber&utm_campaign=devchat&utm_content=homepage) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Twitter: Thomas Randolph ( @rockerest ) (https://twitter.com/rockerest) JSJ 425: The Evolution of JavaScript (https://javascriptjabber.com/jsj-425-the-evolution-of-javascript) Temporal (https://tc39.es/proposal-temporal/docs/) import assertions (https://tc39.es/proposal-import-assertions/) JSON modules (https://tc39.es/proposal-json-modules/) The TC39 Process (https://tc39.es/process-document/) Observable (https://tc39.es/proposal-observable/) Partial Application for ECMAScript (https://tc39.es/proposal-partial-application/) ES pipe operator (2021) (https://tc39.es/proposal-pipeline-operator/) JavaScript Module Blocks (https://tc39.es/proposal-js-module-blocks/) Record & Tuple (https://tc39.es/proposal-record-tuple/) ECMAScript proposal "Change Array by copy": four new non-destructive Array methods (https://2ality.com/2022/04/change-array-by-copy.html) GitHub: tc39/proposals (https://github.com/tc39/proposals) JavaScript Jabber 19 April 2022 (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas O. Randolph (https://rdl.ph/) Picks Charles - The Last Battle (https://www.audible.com/pd/The-Last-Battle-Audiobook/B002UZJF22) Charles - GamePigeon (https://apps.apple.com/us/app/gamepigeon/id1124197642) Dan - Star Trek: Picard (https://www.paramountplus.com/shows/star-trek-picard/) Dan - 103 Early Hints Dan - War in Ukraine Steve - Dad Jokes Steve - Rescinded mask mandates for travel Thomas - My notes to this episode (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas - The Design of Everyday Things by Don Norman (https://amzn.to/3Nifiw8) Thomas - What is Reactive Programming by Kevin Webber (https://blog.redelastic.com/what-is-reactive-programming-bc9fa7f4a7fc) Thomas - War in Ukraine Special Guest: Thomas Randolph.

Today we chat with Thomas Randolph from GitLab, to discuss his Top 10 list of the upcoming TC39 proposals. The list… Temporal Proposal Import Assertions JSON Modules Built-In Modules Observable Proposal Partial Application UUID Pipeline Operator Module Blocks Emitter Proposal +1 Records and Tuples +2 Reverse and Sort Methods on Arrays Sponsors Top End Devs (https://topenddevs.com/) Raygun | Click here to get started on your free 14-day trial (https://raygun.com/?utm_medium=podcast&utm_source=jsjabber&utm_campaign=devchat&utm_content=homepage) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Twitter: Thomas Randolph ( @rockerest ) (https://twitter.com/rockerest) JSJ 425: The Evolution of JavaScript (https://javascriptjabber.com/jsj-425-the-evolution-of-javascript) Temporal (https://tc39.es/proposal-temporal/docs/) import assertions (https://tc39.es/proposal-import-assertions/) JSON modules (https://tc39.es/proposal-json-modules/) The TC39 Process (https://tc39.es/process-document/) Observable (https://tc39.es/proposal-observable/) Partial Application for ECMAScript (https://tc39.es/proposal-partial-application/) ES pipe operator (2021) (https://tc39.es/proposal-pipeline-operator/) JavaScript Module Blocks (https://tc39.es/proposal-js-module-blocks/) Record & Tuple (https://tc39.es/proposal-record-tuple/) ECMAScript proposal "Change Array by copy": four new non-destructive Array methods (https://2ality.com/2022/04/change-array-by-copy.html) GitHub: tc39/proposals (https://github.com/tc39/proposals) JavaScript Jabber 19 April 2022 (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas O. Randolph (https://rdl.ph/) Picks Charles - The Last Battle (https://www.audible.com/pd/The-Last-Battle-Audiobook/B002UZJF22) Charles - GamePigeon (https://apps.apple.com/us/app/gamepigeon/id1124197642) Dan - Star Trek: Picard (https://www.paramountplus.com/shows/star-trek-picard/) Dan - 103 Early Hints Dan - War in Ukraine Steve - Dad Jokes Steve - Rescinded mask mandates for travel Thomas - My notes to this episode (https://rockerest.notion.site/JavaScript-Jabber-19-April-2022-1badf36afe844532922888f5132a25f8) Thomas - The Design of Everyday Things by Don Norman (https://amzn.to/3Nifiw8) Thomas - What is Reactive Programming by Kevin Webber (https://blog.redelastic.com/what-is-reactive-programming-bc9fa7f4a7fc) Thomas - War in Ukraine Special Guest: Thomas Randolph.

Support us on Kofi! (https://ko-fi.com/C0C86NYJW) Design by committee usually has a bad connotation but when it comes to specifying JavaScript, making sure a new feature doesn't break the internet is just too big a task for one person. Today on the show we invite Mark Cohen to talk about what it is like being on the board of TC39, the institution which standardizes the JavaScript language under the ECMAScript specification. We kick things off with some history behind TC39 before diving right into some of the debates around how to implement new features within the committee and the larger JavaScript community. From there, Mark weighs in on the main goal of TC39, that of ensuring cross-browser functionality, talking about why it is such a challenging but necessary project. We also speak to Mark about their current focus of championing the move toward pattern matching in JavaScript, getting into some of the ideas being bounced around as far as syntax and all the possibilities this feature will enable. Our discussion doesn't end there though, as we pick Mark's brain about the processes the TC39 follows for seeing a proposal through from idea to implementation, and also hear about how they adhere to the ‘don't break the web' principle. So for all this and more on Enjoy the Vue, tune in today! Key Points From This Episode: Introducing Mark, their affinity for programming languages, and how they got involved with specifying JavaScript. The origins of JavaScript in the TC39 group created under Ecma International. The role of plenaries at TC39 and how the group comes to decisions via consensus. What the pipe operator is and the different sides in the debate for its syntax. Examples where big contributors to languages felt insulted by communities or decisions. Cool assignment operators like Python's walrus and Rust's turbofish. Whether ‘design by committee' is a bad thing in the case of JavaScript. Mark's perspective that the main goal of the committee is to ensure cross-browser functionality. How TC39 is preventing browser wars using the test 262 suite. The desire for pattern matching in JS and why Mark is championing this. How similar implementing pattern matching in JS would be to reusing switch statements. The intricacies of the syntax and keywords of JS pattern matching and what will be possible. Four phases of TC39 proposals and how they apply the ‘don't break the web' principle. The failed array.prototype.flatten project and what led to the ‘smooshed gate controversy'. Where to find Mark online. This week's picks! Tweetables: “The primary charter of the committee is to make sure that things work across browsers.” — @mpcsh_ (https://twitter.com/mpcsh_) [0:22:12] “Companies still want control of the web and control of the users of the web, right? But there's a lot more protection now. One of the big invisible ways that this happens is a tool that the committee maintains called test 262.” — @mpcsh_ (https://twitter.com/mpcsh_) [0:25:30] “I'm championing the pattern matching proposal.” — @mpcsh_ (https://twitter.com/mpcsh_) [0:27:29] “So that phrase, 'don't break the web' is a common refrain among the committee. It basically reflects our infinite backwards compatibility mandate.” — @mpcsh_ (https://twitter.com/mpcsh_) [0:46:33] Links Mentioned in Today's Episode: TC39 resources: TC39 Homepage/Spec (http://tc39.es) TC39 GitHub (https://github.com/tc39) TC39 Discourse (http://es.discourse.group) TC39 Matrix (https://matrix.to/#/#tc39-general:matrix.org) Proposals: Pattern matching (https://github.com/tc39/proposal-pattern-matching) Temporal (https://github.com/tc39/proposal-temporal) Record & tuple (https://github.com/tc39/proposal-record-tuple) Pipeline operator (https://github.com/tc39/proposal-pipeline-operator) Ecma International (https://www.ecma-international.org) test262 (https://github.com/tc39/test262), TC39 (GitHub) Walrus Operator (https://realpython.com/python-walrus-operator/) What is Rust's turbofish? (https://techblog.tonsser.com/posts/what-is-rusts-turbofish), David Pedersen State of JS (https://stateofjs.com) SmooshGate FAQs (https://developers.google.com/web/updates/2018/03/smooshgate), Mathias Bynens Where to Find Mark Online: Twitter: @mpcsh_ (https://twitter.com/mpcsh_) Github: @mpcsh (https://mpc.sh) Blog/website: mpc.sh (https://mpc.sh) This weeks picks: Mark Cohen Headphones: ÆON 2 Noire (https://danclarkaudio.com/aeon-2-noir.html), Dan Clark Audio Crafting Interpreters (https://craftinginterpreters.com/), Bob Nystrom Baba Is You (https://hempuli.com/baba), Hempuli Oy, Arvi Teikari (PC, Switch, iPad, Android) The Fifty: Mt Stimson (https://www.youtube.com/watch?v=Yov6FzlAuoQ), Cody Townsend (YouTube) Alex My Awesome Jamstack Conf talk (https://www.youtube.com/watch?v=GEDLKKLIkuU), Alex Riviere (Jamstack Conf 2021) Ari Moosewood Restaurant Cooks at Home (https://bookshop.org/books/moosewood-restaurant-cooks-at-home-moosewood-restaurant-cooks-at-home/9780671679927), Moosewood Collective Oscar Slay the Spire (https://www.megacrit.com), MegaCrit (Microsoft Windows, macOS, Linux, Nintendo Switch, PlayStation 4, Xbox One, iOS, Android) Tessa Dumpster Fire - This is Fine Vinyl Figure (https://100soft.shop/products/dumpster-fire-this-is-fine-vinyl-figure), 100% Soft x KC Green What's new in WSL 2 (https://docs.microsoft.com/en-us/windows/wsl/compare-versions#whats-new-in-wsl-2), Microsoft On Your Side, Nathan Fielder (This Hour Has 22 Minutes (https://www.cbc.ca/22minutes), CBC)

Mark S. Miller discusses civilization as relevant superintelligence, the importance and neglectedness of cybersecurity, and decentralized approaches to AI safety.  Even if we don't know yet how to align Artificial General Intelligences with our goals, we do have experience in aligning organizations with our goals. Some argue corporations are in fact Artificial Intelligences - legally at least we treat them as persons already.Mark S. Miller is Chief Scientist at Agoric, and a pioneer of agoric (market-based secure distributed) computing and smart contracts, the main designer of the E and Dr. SES distributed persistent object-capability programming languages, inventor of Miller Columns, an architect of the Xanadu hypertext publishing system, a representative to the EcmaScript committee, a former Google research scientist and member of the WebAssembly (Wasm) group. Music: I Knew a Guy by Kevin MacLeod is licensed under a Creative Commons Attribution 4.0 license. https://creativecommons.org/licenses/by/4.0/ Session Summary: Civilization as relevant superintelligence – Mark S. Miller - Foresight InstituteThe Foresight Institute is a research organization and non-profit that supports the beneficial development of high-impact technologies. Since our founding in 1987 on a vision of guiding powerful technologies, we have continued to evolve into a many-armed organization that focuses on several fields of science and technology that are too ambitious for legacy institutions to support.Allison Duettmann is the president and CEO of Foresight Institute. She directs the Intelligent Cooperation, Molecular Machines, Biotech & Health Extension, Neurotech, and Space Programs, Fellowships, Prizes, and Tech Trees, and shares this work with the public. She founded Existentialhope.com, co-edited Superintelligence: Coordination & Strategy, co-authored Gaming the Future, and co-initiated The Longevity Prize. Apply to Foresight's virtual salons and in person workshops here!We are entirely funded by your donations. If you enjoy what we do please consider donating through our donation page.Visit our website for more content, or join us here:TwitterFacebookLinkedInEvery word ever spoken on this podcast is now AI-searchable using Fathom.fm, a search engine for podcasts.  Hosted on Acast. See acast.com/privacy for more information.

In this episode we dive into the history of Javascript aka ECMAScript and its latest features since ES6. A brief history of Javascript…

Anlässlich der offiziellen Verkündung von ECMAScript 2021 fanden sich Hans, Schepp und Peter zusammen, um nicht nur die Feature-Liste des neuesten JavaScript-Standards zu rekapitulieren, sondern dabei…

It's 2021 - how has NodeJS evolved? Carl and Richard talk to Rob Richardson about NodeJS and much more. Rob dives into the current evolutionary process of JavaScript with the ECMAScript standards and the impact of transpilers to allow developers to use the latest concepts of JavaScript while still remaining compatible with existing browsers. The conversation dives into the Node philosophy of minimal footprint and surface area and the great libraries that help you get going quickly. And then there's WebAssembly!Support this podcast at — https://redcircle.com/net-rocks/donations

It's 2021 - how has NodeJS evolved? Carl and Richard talk to Rob Richardson about NodeJS and much more. Rob dives into the current evolutionary process of JavaScript with the ECMAScript standards and the impact of transpilers to allow developers to use the latest concepts of JavaScript while still remaining compatible with existing browsers. The conversation dives into the Node philosophy of minimal footprint and surface area and the great libraries that help you get going quickly. And then there's WebAssembly!Support this podcast at — https://redcircle.com/net-rocks/donations

We’re just about four months away from the release of ES2021, the latest annual update to the ECMAScript standard, and it will bring with it quite a few quality of life improvements for JavaScript. This...

If you write code on the modern web, it's almost certain that your life has been shaped significantly by Luke Hoban's work. Luke has worked on developer tools his entire career. He started out on Visual Studio, C#, and .NET in the early 2000s, later joined the ECMAScript standards body as a representative of Microsoft, and then became one of the co-founders of the TypeScript programming language. Today, he is the CTO of Pulumi, an infrastructure-as-code company that lets you write your deployment config as code in your favorite language.Luke shares stories from the early days of TypeScript and talks about how it evolved from a two-man team to one of the most successful programming languages and open-source projects. We discuss important inflection points and design decisions that played a key role in TypeScript's runaway success. We also dive into the symbiotic relationship that TypeScript had with another early project just getting off the ground at the time: VS Code. Luke also shares his learnings from his stint at AWS, how his role at Pulumi combines his two passions for programming languages and cloud infrastructure, and how Pulumi brings the niceties of the IDE experience to an area that sorely needs it—infrastructure configuration management.Show notes and transcript: https://about.sourcegraph.com/podcast/luke-hoban/

This week starts with a couple different JavaScript related posts. Our first one looks at how JS dependence is bad for the canned theme market. The second offers an ES5 tutorial on using the .filter()...