Sean: Hi, and welcome to PodRocket. I'm Sean, I'm part of the engineering team here at LogRocket. Joining me today is Ujjwal Sharma, compilers hacker for Igalia, TC39 Co-Chair, JS Internationalization Co-Editor, and on top of that, a core collaborator for Node.js. So, welcome to the show, Ujjwal. Ujjwal Sharma: Hello, thank you. It's a pleasure to be here. Sean: Yeah. Thanks for joining us. So among those many things that I just said that you have on your plate, one of those was a compilers hacker for Igalia. So can you talk a little bit about what it means to be a compilers hacker? Ujjwal Sharma: Well, yes. Thank you. So I tell people that my job is to hack on compilers, which means that, so maybe a little bit of background about Igalia. If you don't know about it, it's a free software consultancy. We work on all sorts of software from, I don't know, the Linux kernel to JavaScript engines and everything in between. My team specifically focuses on compilers. These are at the moment JavaScript and web assembly compilers primarily. Also starting to get into some more sort of non [inaudible] compilers, like LLVM and so on. But generally the idea is to build programming languages and to work on infrastructure that runs code in different contexts and different platforms. Ujjwal Sharma: As you mentioned TC39 already, my job, more or less, is to focus on the programming language side of things and make sure the JavaScript is fun and easy to write and so on. And then later, a lot of these features are implemented within the engines by my colleagues. But yeah, overall as a team, the simplest description would be that we add features to JavaScript. We add features to web assembly, things like Async or Temporal. And yeah, a lot of that involves hacking on these compilers, like V8 from chromium or spider monkey from Firefox. A lot of that is just designing how the features would work or how infrastructurally it would work and so on. Sean: So it sounds like Igalia is very connected to the open source community. Did you first join TC39 and then Igalia? Or what was the order there? Ujjwal Sharma: Right. So that was complicated, but certainly interesting because TC39, see, is in some ways a closed off body. It's not so easy to get involved as a person who's interested in these things, which is partly something that I've been trying to address in the last couple of years now. But essentially there's only a limited amount of involvement that you can have as an outside collaborator, which I did have before I joined as a delegate [inaudible] code from Igalia. Ujjwal Sharma: For a while, in university, I was doing a bunch of open source. Most of that was in node, as you mentioned previously. Then I jumped onto sort of the more engine parts of node. At this time I was writing a bunch of compilers code in V8, specifically. And yeah, I found out about, Igalia, sort of started getting a little bit into TC39 things as I could find. But at some point it seemed that, yeah, I would need to join as a delegate to make an impact. And yeah, then Igalia hired me. So for the first few months I was working as a student, just doing unrelated projects in web assembly land and so on. And then I decided to start working there, first part time as working on TC39, but I was still studying. And then after I finished university, I started working full time. Sean: Nice. So it sounds like you have started as a tinkerer as a student. And when did you realize that this could kind of become a career path? Then I guess also, what would you recommend to others who are sort of interested in contributing to that space? Ujjwal Sharma: Right. Yeah. Thank you. That's a great question. I did start off just doing stuff, just tinkering, just passing time at university, for the most part, within, when I was working on node. The turning point that, Ray, I'm trying not to make it into some sort of story, but the turning point happened when there was a node collaborator summit in Berlin. Ideally I would not go. I was a random student, I like writing code, I was doing that. I wasn't interested in going out and meeting people, but there was a few things that I was working on back in node, which would benefit from more discussion. I could get more involved in some things. And generally it was like... It informed to me that it would be a good idea to come. And somehow everything worked out. I have no idea how I managed to end up in Berlin all alone at, I don't know, 18 or 19 with no idea. I'd never traveled internationally or anything before, but it worked. Ujjwal Sharma: So I went there, and that sort of opened up a lot of possibilities for me. Now I realize, okay, how cool it could be to go to all these events and meet people. A lot of people I met would end up giving me great ideas. And some of the people from the V8 team from Chromium were there who would go on to help me out a little bit to get into the code base. And then from there, I realized, okay, this is a career path I could generally, I don't know. At the time I was thinking, okay, I could get an internship at Google. That's what I'm looking for. And then over time I realized many things in the technical space. I started to know more about my own interests and I found out about Igalia. So I thought, okay, this is maybe something that's more up to my speed. Ujjwal Sharma: So I applied to be a sort of student developer over there, see how things go. And I felt really good during my [inaudible] months, so I didn't even finish my tenure. And so, yeah, it's called the Coding Experience Program where we try to immerse students in open source projects in areas that we work with, but it was a little bit restricting for me because I, due to the rules of the program, I couldn't work on things that Igalia was working on as a project. And, well, Igalia does a lot of things in JavaScript space, which means that I was limited in the space that I was passionate about. And I was, because of that, working on web assembly. But I couldn't make myself not work on JS. So I started dabbling still in TC39. At some point somebody was so frustrated, it was like, let's just hire this person and put an end to this. Ujjwal Sharma: So, yeah, I think in general, the takeaway from me is to socialize, meet more people. It's of course great to write amazing code and you could spend all day solving problems, but the connections that you make in the real world are usually really helpful to show you completely unexpected ideas or introduce you to different directions that you could take. Sean: Yeah. I think having those mentors really important as well, because then you meet people who have been down the path and it just at least makes you believe for yourself, at least in my experience, that your goal is attainable. But you mentioned TC39. I think it could be important to back up for a second for the listeners who might not be familiar. I guess just define what TC39 is, and what impact does it have on the kind of day to day work of developers? Ujjwal Sharma: Right. So TC39 in my top list of most descriptive names ever doesn't say anything about what it does. It is, well, the name says that it's the 39 technical committee of this European Computers Manufacturers Association, which also doesn't say much. But essentially it's a committee of people, it's a committee of people who come together from different organizations, which is important because there's a limited number of invited experts that are acting as sort of individual free agents here. Everybody else is a delegate from some member organization like Mozilla or Igalia. And these people meet and work together in order to specify JavaScript. So this means making any changes. Of course, we cannot remove features from the JavaScript language not to break the web. Although sometimes we have to, and it's quite complicated. Ujjwal Sharma: But the most important part is thinking about the future of the language, like, okay, what do we add? How do we evolve the language into what people want it to be and what the community needs it to be and so on. And so anything new that you write in JavaScript, any changes that are made to the language, are governed by this committee. So I think it does affect the day to day of JavaScript developers in many ways. People use Babel, for example. The whole idea of Babel is to keep up with all of these things that are happening in TC39 land. And so, yeah, if you use async/await, if you use any of the newer features, chances are that somebody sitting on TC39 right now worked out these features and designed them, and at least tried to make them easier, to make the language easier to write and the features easy to use. Sean: And you mentioned moving JavaScript forward to what the web wants it to be and the community. I guess, how do you achieve that balance of giving developers a more advanced and modern JavaScript, but also, I guess, is it a balancing act because you don't want to change it too fundamentally? Ujjwal Sharma: Right. Yeah. It's definitely a balancing act. I mean, we definitely do not want a Python 3. And one of the important reasons we cannot have it is because we cannot break the web, every JavaScript code that was written, every piece of JavaScript that was written 10 years ago should technically still be working right now. Although some of it is nonstandard so it's more complicated than that. But the thing is that there's all these different stakeholders in the committee, right? There's huge internet companies like Google. There's browser vendors, like Mozilla. There's big internet companies that just do internet content like PayPal and Salesforce. There's consultancies like Igalia, which are just doing work and acting as a buffer between their clients and the community and the committee. There's OpenJS Foundation, which tries to put forward the, act as representatives of the open source community of JavaScript. Ujjwal Sharma: So there's all these different stakeholders and TC39 does not vote on anything. TC39 does not roll forward with things, and instead works on consensus, which means that every single feature that is designed by this committee and it is approved by this committee needs to satisfy all these stakeholders. Now, of course, there's the question of representation. Is the entire community appropriately represented? And many would say not yet. And that's something that we need to work on. But overall, I think the committee already reflects a large spectrum of JavaScript practitioners and researchers and so on. Ujjwal Sharma: Yeah, the act of getting consensus around these different features is essentially a balancing act. Everybody has different priorities. Some people are quite passionate about security in JavaScript and sort of working in that area while other stakeholders care less about them and care about maybe usability and ergonomics. Ujjwal Sharma: So it's always complicated, but I feel that if the features that you're working on are needed and people feel that they're needed, then there's always ways to work forward. This is not a paralyzing condition where this makes us unable to work. And a great example of that is the temporal proposal. I'm not sure if you followed that, but there's so much support, and there's such a strong consensus behind temporal, which is a great indicator of how widely requested it is. Across all the spectrum of the committee, as well as the community I feel that people have essentially shed their bad blood and come together in support of this proposal across many aisles. Sean: Yeah. It's good to see so many different people coming together and have a shared interest despite coming from different backgrounds, some maybe company, or as valid as a consultancy, but all agreeing on something. So what is the temporal proposal for people in our audience who might not have heard of it? Ujjwal Sharma: Right. So temporal, to introduce temporal, one must introduce date in JavaScript. So JavaScript has a date object. This date object was done on, it was part of the first draft of the programming language. It was done in around 1995. And almost completely, I wouldn't even say inspired by because it's almost a complete copy of the Java date object. So the Java date object in 1995 was already controversial for being terrible, for lack of a better word. So JavaScript already started off at the wrong foot. And as time went on, and people started using JavaScript for more and more serious applications, I think it became more and more evident. Ujjwal Sharma: By the time a lot of the newer batch of the current developers would've rolled around, I think moment JS was already the status quo where nobody would ever use broad date. That was just a bad idea. Everybody hated it so much. I could go for one [inaudible 00:17:22] and nail a list of complaints, but if that's belaboring the point, the point is that things got so bad. So there were many iterations. First, people tried to sort of damage control data bit that didn't completely work, that worked a little bit, but with varying results. Then moment happened and that went on for a bit. And then everybody got quite upset about the bundle sizes and then Luxon and sort of date functions and all these. Ujjwal Sharma: But all of this was always a cruel reminder of the failure of the JavaScript language that a powerful, as we'd like to say in popular programming language such as JavaScript, has God awful data handling system, which is something which is quite widely used. It's no Atomics. There's real users of data out there. And that was said. Ujjwal Sharma: So some of the, a subset of the maintainer group of moment JS came together with a bunch of interest with people in TC39 and decided, okay, this needs to be done. So temporal essentially started off as a vision of what date should have been, a way to fix date and sort of restore order to provide a decent API. Maybe not as powerful as to fix the world, but serve as a decent solid basis for date time applications. Basically an API that would not make people instantly hate the programming language. Ujjwal Sharma: And then it went in all sorts of directions, which, I mean, yeah, a lot of us are quite excited about. We used to joke about adding support to four time dilation in temporal. Well, that's, at least for now, it's still a joke, but the idea is that temporal went from there, as a replacement for what date should have been to such a far point in that it's, I think I could safely assert that it's the most futuristic sort of powerful date time API right now. It does so many things, including things like third party calendars, custom calendars, like you could totally operate within the Hebrew calendar and not have to worry about anything. It would just handle that. It does, of course, things like time zones, which are more expected these days, but yeah, more or less the temporal proposal has pushed the dates and times space so far that I'm right now, well, before this call, and after this, I've been working on the update to the well known timestamp format to make some changes that would sort of push the space forward and allow more interesting things to be done. Sean: Well, I'm certainly excited to get to play with it. And it's funny that you mentioned moment, cause I think every JavaScript project that I've ever worked on has included the moment JS library. So it's cool to see that you're getting them maintainers of that library involved. Speaker 3: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Sean: And I guess I'm curious about the life cycle of sort of a proposal. Do they get to the point where they're implemented and you can kind of mess around with them, or are they more like specifications that you gather consensus on, and then if people agree that it's worth doing, then you go ahead and implement it? Ujjwal Sharma: Yeah. I think the life cycle is very, very variable. It depends from case to case. Since we've talked so much about temporal, temporal is a great example because it did start a while ago, and only now it is at the point where it's being implemented more or less across all the engines that we know and love. I feel that by the end of this year, it would be in all major browsers, but all this time, if you think about purely in terms of start date and end date, temporal would be a very long proposal. But that ignores the fact that temporal is also probably the biggest proposal, size wise, that has happened in JavaScript yet. Ujjwal Sharma: You mentioned at the start that I was the co-editor of the internationalization part of the language. Just as a reference, the temporal proposal, which is just a proposal is larger than the entire internationalization part of the whole programming language. So, and that has a bunch of constructors also. So you can imagine that even though temporal has taken a while, this was not, we didn't cash any slack during any of this time. The small group, the sort of subcommittee that is working on temporal was constantly at work. Ujjwal Sharma: Then there's proposals like decorators. I didn't don't know if you heard, but decorators recently finally happened. So it's at stage three, which means that now it'll be your favorite browser soon. But the point is that it took, I don't know, over 10 years now. Decorators has been here forever and we keep discussing it, but it was just stalled for so long because nobody agrees about it. Everybody had, of course, all sorts of opinions about it. It was so hard to convince everybody to go ahead with a particular version of it, right? Type script would prefer a certain version that would fit well with type script, and then others who don't necessarily write type script or care about it and want a different kind of decorator that does different things would, they'd prefer that. Ujjwal Sharma: So there's all sorts of different life cycles. It depends on the proposal and how controversial it is, how much work it needs to be actually put in. But yeah, as I mentioned, there's a stage process. So there's a stage three where we decide, okay, we've designed this and sort of specified this, written every single character in a cushy chairs, and this is ready to be in the wild. And once something is at stage three, we usually never change it unless it is in respect to feedback from the implementation. Maybe Chrome comes to us and says, this is just impossible to do. What are you talking about? Or the community feedback. What if somebody comes and says, okay, you've designed this feature and implemented it, but it's completely unusable. So you need to go back to the chalkboard. Ujjwal Sharma: But unless either of those things happen, you usually go ahead with it. So stage three is usually a good indicator of, now this feature is being implemented or is already implemented. And once it's implemented in a few engines out there and very happy also with the specification text, so that's an aspect als. We say, okay, this is a part of the language now. This is published, and it goes onto stage four, which is the final stage. Sean: So is it fair to say stage three is kind of like a staging ground where it's pretty much set and it's just giving time to the browser vendors to implement the features? Ujjwal Sharma: Right. Exactly. Like it's just a buffer phase between design and yeah, this thing exists. To be sure that, okay, did we do this right? Or there's also some leeway for, as I said, the community. We could realize after implementation and everything, but before stage four, so that means that it's not technically a part of the JavaScript language. It's not safe to use this right now. But the idea is that maybe we'd realize for some proposal that, okay, this was a mistake. This is not right for the community. Or maybe the community would inform us that, okay, this is completely unusable, or this is not beneficial, or this is a something that we call in TC39 lingo a foot gun, it's harming the user. Ujjwal Sharma: So yeah, in those cases, we do reserve the ability to call it back. But in general, that doesn't happen. I mean, usually the vetting process to get to stage three is harsh enough that whoever gets to stage three is more or less guaranteed to be part of the language. Sean: Got it. And there's another area where TC39's been making a lot of progress is this area of concurrency. And so you recently gave a talk, multi core JavaScript, past, present, and future at a few conferences this year. Can you give us an overview of why it's important to understand JavaScript's history of multiple cores? Ujjwal Sharma: Yeah. Thank you. So this talk that I gave was another one of my attempts to get the community to somehow tap a little bit into the inner workings of TC39 and sort of how this weird shadowy lobby group is operating, because people hear about all the proposals. And when you hear about huge self-contained proposals like temporal, I think it's good and it's fine. It's easy to get excited about them. But that doesn't apply to everything. Ujjwal Sharma: In general, when JavaScript was created, computers worked very differently and CPUs worked differently. I remember when I was younger being completely obsessed with the numbers. So I would, anybody talking about their computer, okay, how many gigahertz? What's the frequency of the CPU? Now nobody cares about the frequency of your CPU. Do you know, what is the frequency of the CPU, of your mobile CPU? Nobody cares because there's so many cores in our computers these days that we don't need huge cores with a lot of frequency. We can, this allows us to easily split up work and also have different cores, some of which are sort of weaker, but low power, low heat cores, and so on. So the newer, M1 Mac books, if maybe you're using one, have 10 cores or 12 cores, and these are all sort of heavily optimized for different kinds of workloads. Ujjwal Sharma: So, so this is the direction that the, that the hardware industry took, but, well, not unfortunately, but because JavaScript was created in a completely different era of computing, this means that it's not well adapted to write code, which effectively utilizes this new hardware. There's a lot of work that we're doing in order to enable JavaScript to be native, to multi core environments and make the best of this hardware capabilities. But all of these things are happening in sort of dissociated proposals. So you hear about, let's say the struts proposal, and somebody, maybe you're at lunch at work and somebody tells you, oh hey, TC39 did structures. And you're like, okay, it's fine, I guess. Sounds like a decent language feature, but why? Okay, are these people just adding stuff to the language for the sake of adding stuff to the language? Ujjwal Sharma: And that's not the case because yeah, we're advancing proposals one at a time, sometimes simultaneously, but focusing on them individually. But that doesn't mean that there isn't a coherent picture. And so this is what I try to point people towards in the talk. I try to tell them, okay, how are all these different proposals connected and how they're all taking us towards a common goal, which is, we need to run the JavaScript code on multi core hardware, efficiently. The process, essentially, which the talk as well as normal TC39 discussions take, is, well, what do we have, and what do we need in order to get there? And then let's break what we need into as many tiny proposals as we can and advance them. Ujjwal Sharma: So, yeah, that's more or less what I try to convey in the talk. It's not the most practical talk, I would say, because it only really talks about features that do not yet exist or sort of [inaudible 00:32:49] tries to talk about the concepts of multi core programming and concurrent programming, but not really go in to anything practical. But I hope people like the fact that they have a little more insight into the workings of this committee. Sean: Yeah. I learned a ton about like a history of concurrency in JavaScript while watching it. And yeah, it does seem like there's no more free lunch in terms of the free speed up gains as computers get higher clock speeds as we're really going more in the direction of more cores now. And I guess that puts more of the burden on software developers to take advantage of that and harness that. Sean: So I guess, going into watching that talk, I knew about that there was this web worker thing, and you can do something and spun it off in a different thread and then kind of wait for it to finish. And then there's also this atomics feature set. I guess, how do you see those two things kind of coming together and what is TC39 planning to do? I guess you kind of alluded to this as in the future, in terms of providing different types of concurrency approaches. Ujjwal Sharma: Right. So I mentioned in the talk that there are essentially two different approaches that you can take to concurrency in JavaScript. There's a sort of more webby approach where you can encapsulate everything in promises and asynchronous calls and not really have to deal with the, well, in code lingo, logistics of how these tasks are actually executed and so on. You're assuming that there's a good event loop implementation that the implementation is backed by. In most cases, that would be the case, unless, I don't know, your users are running your JavaScript code on a smart fridge, probably, maybe not. But overall, it works out. Ujjwal Sharma: Then there's another approach, which is quite a bit more complicated, at least in my experience and opinion, which is the sort of more traditional multi threaded approach. And this was before ML and actors and all these things existed. This comes all the way from C land, where people had raw threads and they could run arbitrary code on raw threads. But like everything with C, you had to deal with everything yourself, and you might be open to very nasty bugs or data races, and you had to synchronize yourself. Ujjwal Sharma: The modern thread approach to concurrency in JavaScript is not quite as wild as the original C approach that it borrows from. But there are some... In some way you could say some flashbacks to that era where you have things like atomics, which are hard to use. You can use them to synchronize your code, but it's not ergonomic. And I would not expect any average JavaScript developer to be able to reason around atomics. I cannot. So it's sort of a flashback also in that way that it's an immense, complicated space, immensely complicated space for really no reason. It could be made way more ergonomic and it can still remain more or less as fast as it needs to be. Ujjwal Sharma: Now it's another story how, maybe I'm skeptical of how fast it would be, but overall, I think we need to improve a lot, especially on the second approach. And this is where, as you said, atomics or web workers come in. Web workers are such a huge improvement over raw threads that C used, or I think Python still uses if you don't use anything like twisted, which, yeah. Again, even loop implementation. So yeah, I think in order to make any of these tenable for developers, we need to do a lot of work. We need to introduce a lot of tools. We need to introduce a lot of mechanisms that people can utilize to more confidently, I feel, at least in the second domain, write code, because it makes a lot of people really nervous to be able to use things like atomics. Sean: Yeah. And you gave, I thought it was a really good metaphor in the talk. It was a picture of a sign that said, you must be this tall to write threaded code, and it was pretty much at the ceiling. I thought that it was funny, because I think anyone's written threaded code has encountered just really strange and confusing bugs. It is just simply is harder to write than non threaded code. And do you feel that users of the web will inevitably be exposed to a new class of frustrating bugs, like deadlocks and data races? And I guess how important is designing these concurrency premise in JavaScript correctly to prevent that from happening or to at least reduce it as much as possible? Ujjwal Sharma: Yeah. I think it's inevitable if we do not explicitly avoid it and I would like to explicitly avoid it. I mentioned in the beginning, my university days where I was sort of working on all these open source projects, one of the reasons I hated to do my classes was that because we had to go to classes and draw Gantt charts in order to understand like how to write multi threaded code. I'm not sure if my university's representative, but I would say that the average computer science grad would spend at least one or two semesters just learning how to write multi threaded code and not like completely destroy everything. Learning about blocks, learning about, I really hope nobody is drawing Gantt charts, but yeah, that's the reality of this space. If you're writing operating systems, you probably care about these things. Ujjwal Sharma: But I feel that one of the reasons I'm so motivated about JavaScript is that I think it's a very approachable programming language. I think it's very easy to pick up and it opens up so many possibilities for you. It's not a toy programming language like scratch. You can learn JavaScript, you can teach JavaScript to kids or to adults, and they could build really useful things right off the bat. I personally, and I think there's a bunch of people who agree with me on the committee, that we need to preserve, that we need to keep JavaScript as, as a good approachable programming language. And that will not be the case if you have all these complicated ways how to write code. Ujjwal Sharma: I mean, this almost technically happened during like the whole angular days, the angular one days I'm talking about, where already, it felt that JavaScript was getting so complicated and people were dabbling in all these things. And then ES6 happened, and then now I feel that JavaScript is much easier to write. I feel that somebody who writes JavaScript today doesn't even have to care about prototypes for the most part. Maybe I'm wrong, but this is, you have to understand, that these are conscious choices by this committee, who are constantly trying to make the language easier to read, easier to write, and easy learn. And of course nobody's perfect, but there's a lot of feedback from educators and researchers and otherwise community members, which guided us through the ES6 days and hopefully they'd continue to give us feedback during this multi core evolution era. But yeah, I hope that we come up with the solution that can utilize the hardware and not sort of sacrifice on that without being really complicated to get into or even read code. Sean: Yeah. No, I think JavaScript was the first language that I learned and I found that it was relatively not that intimidating to get into. And I think modern JavaScript is so fun to write. And so, yeah, I think it'd makes sense to prevent making concurrency, I guess, to avoid introducing a [inaudible], like you said earlier. But before we wrap, is there anything that you want to plug or I guess where can we find you online for our listeners? Ujjwal Sharma: Thank you. Yeah. This has been really fun. So you can find me online at Ryzokuken. That's my username everywhere. It's spelled R-Y-Z-O-K-U-K-E-N. And yeah, that's me on Twitter or GitHub, whatever, if you want to rant about my proposals or my code. And yeah, TC39 has their website on TC39.es. You can also go from there to our chat rooms or whatever, our GitHub. I would be very happy if people get got more involved, I'd be happy to help as well. So yeah. Feel free to get involved or just hit me up directly if you have any requests or ideas about what we could do next and so on. Sean: Awesome. Well, yeah, it was really great having you on. Thanks for joining us today. Speaker 4: Thanks for listening to PodRocket. You can find us at PodRrocketPod on Twitter, and don't forget to subscribe, rate, and review on apple podcasts. Thanks.