Off The Main Thread Podcast

TC39 Roundup Drama Edition Part II: JS0 and JSSugar

In this episode, Surma talks about a presenation-maybe-soon-to-be-a-proposal "JS0", which explores the idea of splitting JavaScript into two specifications: JS0, focusing on security, performance and capabilties, implemented by engines; and JSSugar, focussing on developer productivity and syntactic sugar features implemented by build tools.

Notes & Corrections:

  • Yes, I know, people still do have to step through assembler. But I stand behind the essence of my point: The debug symbols for compiled languages feel very reliable. We should be able to at least match that reliability in JavaScript.
  • Guy Bedford currently works at Fastly.

Resources:

Transcript
  1. Surma:Welcome back! Welcome back? No, this time it's actually a welcome back to a brand new episode of OTMT. I am Surma.
  2. Jake:I love the way you started. Too high there, realised you couldn't sustain it, and just
  3. Jake:came down an octave for the rest. I'm Jake, by the way. Hello.
  4. Surma:And this is our podcast. And thanks to Shopify for letting us do this and giving us some money.
  5. Jake:I mean, they don't give us money to do this. Well, they pay for the hosting, but, yeah.
  6. Surma:They do, yeah. Yeah, it's how society works.
  7. Jake:They pay us to do other things. Which I think is fair enough. That seems fair, doesn't it?
  8. Jake:Right, so are you going to apologise to the listeners for what you did?
  9. Surma:Yes, it was genuinely not planned to make this a two-part. I'm basically pulling a wicket.
  10. Jake:What's that? No?
  11. Surma:Like, didn't you hear the whole drama that wicked the movie where they turned the musical into a movie? A two-hour-thirty-movie?
  12. Surma:And it turns out it's a two-parter, so it's gonna be another two-hour-and-thirty-movie coming out, even though the musical itself is two hours long with intermission.
  13. Surma:What? I am shocked. Shocked, I say!
  14. Jake:I didn't know that. OK, yes, OK, that's outside of my sphere of knowledge. Hey, look, musicals
  15. Jake:are not my thing, I have to say. Yeah. Ah, oh, there you go. I mean, I've seen musicals.
  16. Surma:Well, that's what happens when you live with a musicologist.
  17. Jake:I've seen enough to know. I was once musical curious, but I gave it a try and I just decided
  18. Jake:I just didn't like it. So I'm not against people who like musicals. I think it's fine.
  19. Surma:As long as they do it in their own home.
  20. Jake:Yeah, as long as they don't rub it in my face, I'm fine with it. And I'd say, you know, they're
  21. Jake:fine people, it's just not for me.
  22. Surma:Yes, so my sincerest apologies to our listeners. I started the last episode saying,
  23. Surma:we're gonna talk about two proposals, and then we jabbered on about the first one for so long that the second episode felt like abuse.
  24. Surma:So, that means we now have an entire episode where we talk about the juicy, the dramaful, the beautiful JS Zero proposal.
  25. Jake:Oh, here we go. Yes, yes, finally. Right. This is what I want.
  26. Surma:Shall we just jump straight in?
  27. Jake:Just give me all the drama. Come on. Been waiting weeks for this.
  28. Surma:So, I guess, first asterisk. Is it a proposal? I'm actually not sure.
  29. Surma:So, it was talked about in the last face-to-face meeting of TC39 in October,
  30. Surma:and it was just a slight deck scheduled in the open-ended discussion category.
  31. Surma:Well, that's the thing, right? So, this slight deck that was presented was linked to in the agenda,
  32. Jake:And it kicked up a big ol' stink, if social media is to be believed.
  33. Surma:which is public, as it should be for a standards body, so I'm applauding them.
  34. Surma:And the slight deck was, you know, in the open-ended discussion category.
  35. Jake:Mmm.
  36. Surma:was linked to in the agenda, which is public, as it should be for a standards body, so I'm applauding them.
  37. Surma:And the slight deck was, you know, made and presented by Shu, our former colleague at the Googles.
  38. Surma:But the slight deck also lists other people, one person from Google, that being Shu,
  39. Surma:two people from Mozilla, two people from Apple, one person from Modable, and one person from Sony.
  40. Surma:So, this is not just a proposal, or this is not a slight deck, I should say, where they go like,
  41. Jake:Oh, interesting, because, I mean, with the drama that I saw, and like I say, I've, well,
  42. Surma:LOL, Google doing shit, but this was actually, you know, run by other people and other browser people.
  43. Surma:LOL, Google doing shit, but this was actually, you know, run by other people and other browser people.
  44. Jake:like I said in the previous episode, I've been, because I knew you were going to do
  45. Jake:this episode, I've been trying to keep myself away from it, so I'm hearing this for the
  46. Surma:LOL, Google doing shit, but this was actually, you know, run by other people and other browser people.
  47. Jake:first time, but very much the information I saw suggested that Google is trying to destroy
  48. Jake:JavaScript forever.
  49. Surma:Yes, and that is true. No, no it's not.
  50. Surma:So, there is a delineation that is also, again, made very explicit in the slight deck itself.
  51. Surma:These people who are listed on the first slide as like, you know, we want to talk about this,
  52. Surma:they all agree on the problem at hand, and they agree that something should be done.
  53. Jake:Mmm.
  54. Surma:The actual, quote-unquote, proposal, the thing that is proposed, showcased as a potential solution for this problem,
  55. Jake:Oh, okay, so this is where the Google's killing JavaScript bits come into it. I see, so it's
  56. Surma:called JS0, is by Google. It's the preferred solution by Google,
  57. Surma:and may or may not be the preferred solution of these other people working for these other companies.
  58. Jake:not totally made up. Oh.
  59. Surma:Yeah, maybe. That being said, when I looked to a slight deck, I liked it.
  60. Surma:I was not, there's nuances, and we hopefully, we're going to talk about all of these,
  61. Surma:but as not a language implementer, JavaScript implementer,
  62. Surma:but someone who has recently dabbled in trying to build their own language,
  63. Surma:I thought that proposal is quite good.
  64. Surma:Anyway, the reason the drama is interesting is because it was presented on October 8th.
  65. Jake:Okay, okay, come on then.
  66. Surma:The drama on Twitter was on October 5th.
  67. Jake:Oh.
  68. Surma:So, someone stumbled over, because the agenda is public, and the slight decks were linked,
  69. Surma:somebody stumbled over this, and decided to do a Twitter thread.
  70. Jake:I mean, look, I don't blame them for that. That's a juicy slide deck. I, look at this,
  71. Surma:It's a juicy slight deck.
  72. Jake:look at this data, it looks utterly terrifying. We should talk about what's in the slide deck,
  73. Jake:because I have looked at the slide deck.
  74. Surma:That's what I want to talk about.
  75. Surma:So, I haven't really made up my mind whether I want to link to the Twitter thread,
  76. Surma:because I feel like it did go viral, at least for the standards of a TC39-related topic,
  77. Surma:but also, I don't want that person to necessarily get griefed if people think they were being a bit overzealous,
  78. Surma:but also, I worry that the thread might not age super well.
  79. Surma:So, I'd rather link to the slight deck and the official things, and people can hopefully,
  80. Jake:Yes, so it was basically that Google is replacing JavaScript with Dart, right?
  81. Surma:well, I'm going to say, form their own opinion after listening to my opinion for what is probably going to be two hours.
  82. Surma:So, let's see.
  83. Surma:So, I'll try and explain this proposal, the slight deck, and how I understand it, and how it's motivated,
  84. Surma:and maybe I can weave in a couple of the misunderstandings or the concerns that I've seen, and talk a bit about them.
  85. Surma:No, that was about ten years ago.
  86. Jake:Right.
  87. Surma:They did do that, and then they backpedaled on that.
  88. Jake:Okay, cool, good.
  89. Surma:This one is actually, at its core, quite simple.
  90. Jake:All right.
  91. Surma:It splits the JavaScript language into two layers.
  92. Jake:Right.
  93. Surma:There is the JS0 layer, that is JavaScript, as it is implemented by what TC39 calls implementers.
  94. Surma:So, those are the engines, the browsers, the BUNs, the DNOs of this world.
  95. Surma:Well, I guess, you know, both BUN and DNO actually just use an engine from a browser, but you know what I mean.
  96. Jake:Yes, sure.
  97. Surma:And JS0 would probably be what JavaScript is today.
  98. Surma:Kind of like, that's JS0.
  99. Surma:The second layer, second part, is JSSugar, which would kind of be its own separate specification,
  100. Surma:but a proper, like, standard specification, and that's the JavaScript that developers write.
  101. Surma:So, now there's a separation between what browsers or what implementers can execute, and what developers would write.
  102. Jake:Okay, and so there's nothing new about this. I mean, we've been doing this for, well, we've
  103. Surma:Kind of, yeah.
  104. Surma:Exactly.
  105. Jake:had that split for years, right? Like, we've, I know that when I open up, like, JSpin or
  106. Jake:CodePen or whatever, like, I'm in raw JavaScript mode, and whereas when I'm pretty much writing
  107. Jake:code for most of the time, I'm writing TypeScript, so I am writing some sort of sugar on top.
  108. Jake:Okay.
  109. Surma:I think that's where a lot of the tension was seen by some of the developers who feel strongly about writing vanilla.
  110. Surma:So, we can dive into that a bit.
  111. Surma:So, the idea would be is that now, basically, it is part of the standardized process of writing JavaScript
  112. Surma:is that there has to be a translation tool that translates JSSugar into JS0.
  113. Jake:Cool.
  114. Surma:And you're right, that is already reality in most scenarios.
  115. Jake:Wait, do I have to type this out?
  116. Jake:Yes, you do.
  117. Surma:Like, you have your Babels, or your SWCs, or Rolldowns, or TSC.
  118. Jake:Okay.
  119. Jake:Okay.
  120. Jake:Okay.
  121. Jake:Okay.
  122. Jake:So, I'm going to type it out.
  123. Surma:You have, usually, in any non-throwaway setup, a tool that processes your JavaScript.
  124. Jake:Okay.
  125. Jake:Okay.
  126. Jake:Okay.
  127. Jake:Okay.
  128. Jake:Okay.
  129. Jake:Okay.
  130. Jake:Okay.
  131. Jake:What was it?
  132. Surma:At the very least, for minification, but most of the time, you have some sort of target ES2016,
  133. Jake:Okay.
  134. Jake:Okay.
  135. Jake:Okay.
  136. Jake:Okay.
  137. Jake:Okay.
  138. Jake:Okay.
  139. Jake:Okay.
  140. Surma:because you want to write ES2020 and use newer features, but then it gets transpiled down to an older version of JavaScript
  141. Jake:Okay.
  142. Jake:Okay.
  143. Jake:Okay.
  144. Jake:Okay.
  145. Jake:Okay.
  146. Jake:Okay.
  147. Jake:Okay.
  148. Jake:Okay.
  149. Jake:Okay.
  150. Surma:because it has broader support by browsers, and so you have to worry less.
  151. Jake:There's two worlds where this could happen.
  152. Surma:And this is kind of like, what if we standardize that?
  153. Surma:And it's not just for the LOLs, right?
  154. Jake:Or two ways it could go.
  155. Jake:One way would be like, okay, TypeScript is now brought in as part of JS Sugar.
  156. Jake:It's standardized, so it's now not just Microsoft making all the decisions.
  157. Jake:It's more of a sort of cross-company thing.
  158. Jake:But it's kind of acknowledged that this will never work just straight in a browser console.
  159. Jake:It's always going to be something that is compiled down to normal JavaScript.
  160. Jake:And I am actually fine with that, because I never really had an expectation of TypeScript
  161. Jake:ever making it into browsers proper.
  162. Jake:The other way it could go is that new features that developers want come along, and user
  163. Jake:agents, you know, the people on TC39 that are very powerful, because they write the
  164. Surma:I think this is the line that has to be made.
  165. Jake:JavaScript engines.
  166. Jake:They're part of browsers.
  167. Jake:They're part of, you know, Google, Firefox, Apple.
  168. Surma:I think this is the line that has to be defined and then carefully walked.
  169. Jake:They say, we can't be bothered with that, so it goes in JS Sugar.
  170. Jake:And that's where everything goes from now on, and it really forks the language completely.
  171. Jake:And features that you would expect, like maybe things like async await, you know, in this
  172. Jake:new world would have ended up in Sugar and never worked in the browser proper.
  173. Jake:And I think that's the case that people are afraid of, and so am I, I think.
  174. Surma:Because I think that is the risk.
  175. Surma:But the motivation that they list in the slide deck, I actually have some sympathy for.
  176. Surma:Because the tension that they very explicitly describe is,
  177. Jake:Thank you.
  178. Jake:Thank you.
  179. Jake:Thank you.
  180. Jake:
  181. Surma:they, as implementers and as standard body contributors,
  182. Surma:they're in this to help developers be productive in JavaScript.
  183. Surma:They want to make sure that they can use the paradigms that they need and want,
  184. Surma:and that they can express all the things they need to express to write good web apps.
  185. Surma:But at the same time, JavaScript has become so ubiquitous and is used in so many different forms and shapes
  186. Jake:Thank you.
  187. Jake:Thank you.
  188. Jake:Thank you.
  189. Jake:
  190. Surma:that each addition to an engine, and that's what JavaScript language features are,
  191. Surma:they're an addition to an engine,
  192. Surma:needs to come with a lot of work to ensure stability and security and, of course, also performance.
  193. Surma:Because that's, in the end, what the end users feel.
  194. Surma:And that is arguably the main responsibility of the implementers, right?
  195. Jake:Yeah, that's the thing.
  196. Surma:They need to allow developers to do the thing while keeping the things stable and fast and secure for the end users.
  197. Surma:And I think most of us, many of us at least, already feel like JavaScript evolves very slowly.
  198. Jake:It's like, it's not like CSS, which seems to like, especially these days, is growing
  199. Jake:features at an amazing rate, whereas, as you say, JavaScript sort of, yeah, it kind of
  200. Surma:Yeah.
  201. Jake:has a couple of features a year.
  202. Surma:But from an implementer's side, it's kind of like it's actually evolving too fast almost.
  203. Surma:They struggle to keep the bar for performance and security that they have set for themselves
  204. Surma:or have been set for them by others.
  205. Surma:Just implementing support for a syntax is one thing, but then doing it correctly so it's fast and secure,
  206. Surma:I think it's easy to forget how much work goes into it.
  207. Surma:I don't want to speak for it because I've never done it myself.
  208. Surma:I've never worked on the engine myself.
  209. Surma:But I can see how, you know, we know that when forEach and map came around,
  210. Surma:that people were like, oh, but for loops are faster.
  211. Surma:And then work went into to make these functional paradigms faster because people wanted to use them
  212. Surma:and it actually has additional benefits for optimization.
  213. Surma:It's like there is a lot of long tail work for each of these features so that they actually make sense.
  214. Surma:And so basically, this split in audiences, one audience being developers who want to be productive
  215. Surma:and expressive and write terse and good code, optimized code,
  216. Jake:But that's the bits I'm worried about.
  217. Surma:and the other audience being end users who want a reliable and stable and high-performing engine
  218. Surma:in their browser and all the web apps work,
  219. Surma:it's kind of the split that is now reflected here in the language.
  220. Surma:So, JS 0, I would assume, would end up being very slow-moving as a language.
  221. Surma:I assume it would almost be frozen.
  222. Surma:I think JS 0 would only evolve for things that cannot be built at the level of JS Sugar
  223. Surma:or things that are just not working efficiently when implemented at the JS Sugar level.
  224. Surma:For example, I would say something like generators and async generators
  225. Surma:because they're not just like a simple desugaring.
  226. Surma:They have to generate a whole state machine and require a runtime.
  227. Surma:And I think that would be an example where that is something that goes into JS 0
  228. Surma:rather than into JS Sugar.
  229. Surma:Similarly, shared structs.
  230. Surma:That is something that I do not think can be realistically built at the JS Sugar level
  231. Surma:and be compiled down to the status quo.
  232. Surma:That is something that needs built-in engine support
  233. Surma:and also something that, as a result, will need lots of time being reviewed
  234. Surma:from a security and privacy perspective with Spectre and Meltdown
  235. Surma:and all the things that kind of factor into this.
  236. Jake:Yeah, so, but let's talk about things like, you know, array.at, which is pretty helpful
  237. Surma:Yes, I think that's a prime example.
  238. Surma:Or like a proposal that recently made it to stage 4 is the iterator helpers.
  239. Jake:for getting, like, the last item of an array.
  240. Surma:Where now iterators have .map, .filter, all these things.
  241. Jake:Is that the kind of thing that's going to end up in JS Sugar land?
  242. Surma:Easy thing to put into JS Sugar.
  243. Surma:Really simple to implement as a simple desugaring.
  244. Surma:It's like you turn one line of code into another line of code.
  245. Surma:It's very simple to implement.
  246. Jake:Yes.
  247. Surma:And I think that's something that's going to be very useful in the future.
  248. Surma:The advantage here would be that JS Sugar advances quicker
  249. Surma:because it's something that is not implemented at the engine level,
  250. Surma:but it is implemented at the tooling level.
  251. Surma:So that's something that only needs...
  252. Surma:There's still a standard and there's still the same processes.
  253. Surma:There's still agreement and consensus needs to be reached
  254. Surma:for something to get into JS Sugar.
  255. Surma:And I think that's something that's going to be very useful in the future.
  256. Surma:for something to get into JS Sugar.
  257. Surma:But then you don't have to actually work through a browser release cycle,
  258. Jake:Yeah, let's say, oh, we can't do array.at in a fast way.
  259. Surma:which is also good for browsers that have very slow release cycles sometimes.
  260. Surma:Once it's landed in JS Sugar,
  261. Surma:it will probably be in tooling a lot quicker than it could be in a browser
  262. Surma:also because it does not have security implications
  263. Surma:because security is solved at the layer below.
  264. Surma:So that's how this is framed as a good thing, as a win-win.
  265. Jake:Or a secure way.
  266. Jake:But then people are going to be using a Sugar implementation, which either has those problems
  267. Jake:or doesn't.
  268. Jake:And if it doesn't have those problems, then why couldn't the browser just do it?
  269. Jake:Or, you know, I understand that if they're writing this stuff in, like, Zygo or C++ or
  270. Jake:whatever, that's, you know, they're in a more security sensitive zone.
  271. Surma:And I think the other difference is whose job is it to implement it?
  272. Jake:But why can't polyfills just be, like, done in JavaScript?
  273. Jake:Within the browser.
  274. Jake:But I guess the one difference between that is the versioning, right?
  275. Jake:It's like, you know, with JS Sugar, it's done by a tool which I'm in control of the version
  276. Jake:of, whereas with browser level features, it's the browser version.
  277. Surma:I think one of the parts that they're calling out
  278. Surma:is that the people who work on these engines
  279. Surma:are already stretched maintaining the bar.
  280. Surma:So if stuff that can be removed as work from them
  281. Surma:and be moved to other people,
  282. Surma:that would help move those more capability-focused features
  283. Surma:to move along quicker or with more confidence
  284. Surma:because they were also listing that there have been some security incidents
  285. Surma:in the last years, I suppose, around JavaScript features that were shipped.
  286. Surma:The other thing that I thought was quite interesting
  287. Surma:is that they spent a lot of time implementing features
  288. Surma:and doing it right and doing it in high-performance ways,
  289. Jake:Yeah, yeah, yeah, yeah, I think for a good long while now.
  290. Surma:which took a long time.
  291. Surma:And they still can't get the ecosystem to actually use these features natively
  292. Surma:because people just continue using their transpilers.
  293. Surma:So this is stuff like async generators or decorators.
  294. Surma:I think decorators maybe is not a great example,
  295. Surma:but async generators are implemented natively in all browsers, I want to say.
  296. Surma:And they just don't see them getting used natively
  297. Surma:because people continue to transpile them.
  298. Surma:For the people who are employed here
  299. Jake:Yeah, yeah, definitely.
  300. Surma:and for the companies that pay these engineers,
  301. Surma:that feels like money wasted.
  302. Surma:And that's not maybe the right way to look at it.
  303. Surma:That's a problem of the ecosystem,
  304. Surma:that they don't automatically look after that transpiler configuration.
  305. Surma:But we know this problem, that an ecosystem is really hard to move.
  306. Surma:We still find people nowadays shipping promise polyfills in their bundles.
  307. Surma:And it's really hard to...
  308. Surma:So I'm really torn here.
  309. Surma:On the one hand, I'm like, this will lead to shipping bigger bundles.
  310. Surma:If the point is that nice syntactically terse features
  311. Surma:are now implemented at the JS sugar level
  312. Surma:and getting desugared, which usually means more code,
  313. Surma:will mean bundles get bigger
  314. Surma:so that developers can use nicer features at the language level.
  315. Surma:Is it significant? I don't know.
  316. Surma:But native support usually means smaller bundles.
  317. Surma:But then again, I can't really blame implementers
  318. Surma:for working with the data they see in reality
  319. Surma:in that even if they do implement it natively
  320. Surma:and would allow you to ship smaller bundles and faster code,
  321. Surma:people don't because for some reason they're too lazy
  322. Surma:or they don't know how to set up their transpilers appropriately
  323. Surma:so that they make use of new native language features.
  324. Surma:And so I can't really blame them for working with that.
  325. Surma:And I think that then they can manage their performance
  326. Jake:I'm really torn on this because on one hand, like, yeah, I see the issue, the security
  327. Jake:issue and whatever.
  328. Surma:without the aspect of a new standard or prescription
  329. Jake:But then I also see, like, two of the richest companies in the world, Google and Apple.
  330. Surma:for better performance on ASP.
  331. Surma:...and there's another big issue with tooling.
  332. Jake:It almost feels like a collusion of, like, well, what if we just stopped competing on
  333. Surma:They seem to have more tools than an implementer
  334. Surma:and they have more options than an implementer.
  335. Surma:And while you realize that their persones are in corporate role here,
  336. Jake:these features and our lives would be much easier?
  337. Surma:what, like, if an employee does the things right here,
  338. Surma:the work is being moved to tooling,
  339. Surma:which I don't think as a concept is unreasonable.
  340. Jake:Yes.
  341. Surma:But if we're talking about reality,
  342. Surma:the reality is that a lot of the tooling people are volunteers.
  343. Surma:I know there's lots of companies that sponsor now,
  344. Surma:like, you know, that make donations for, like,
  345. Surma:Rollup and Rolldown and Veed and, like, all these tools,
  346. Surma:but is that enough to justify you are now
  347. Surma:part of a standards body, if you want to or not,
  348. Surma:and you have to implement this,
  349. Surma:and now you will have more pressure from the ecosystem
  350. Surma:to actually quickly implement any new proposal that lands
  351. Surma:and probably even have, like, stage one, stage two flags in your tools
  352. Surma:because people want to opt in early or something.
  353. Surma:And that is also something that was pointed out
  354. Surma:by other people at TC39,
  355. Surma:where that is just a dynamic that we need to be really mindful of.
  356. Surma:And then, you know, there's also the second order effects,
  357. Surma:which, like you said,
  358. Surma:what does this mean for stuff like CodePen or JSbin?
  359. Surma:I mean, the obvious solution is, like,
  360. Surma:they could run a transpiler in the browser.
  361. Surma:You can run Rollup in the browser.
  362. Jake:It's already the case to some degree with TypeScript, right?
  363. Surma:But is vanilla JS dead?
  364. Surma:And is that a bad thing, right?
  365. Surma:Like, to an extent, I almost see a parallel to WebAssembly here
  366. Surma:where, like, I'm one of the weirdos that does sometimes write
  367. Surma:handcraft WebAssembly because I enjoy that,
  368. Surma:but that's obviously not the intended use case.
  369. Surma:Will it be the same with JS0 at some point,
  370. Surma:where people go, like, I'm a weirdo, I write JS0,
  371. Surma:and most people just actually write another language
  372. Surma:and it gets compiled to JS?
  373. Jake:Yes.
  374. Surma:I think this proposal has merit.
  375. Jake:Yes.
  376. Jake:
  377. Surma:There is something to be said about, like,
  378. Surma:acknowledging the reality of how JavaScript is used today
  379. Surma:and actually standardizing it.
  380. Surma:The fact that even just now being able to talk,
  381. Surma:you know, vanilla JS is always a bit hand-wavy
  382. Surma:because, like, what is vanilla JS
  383. Surma:if it's constantly evolving in the browsers?
  384. Surma:The split of JS0 and JS Sugar,
  385. Surma:even though maybe that's not the names, right,
  386. Surma:but, like, having those as well-defined
  387. Surma:and even standardized entities feels good.
  388. Surma:Whether it actually means just,
  389. Jake:Yeah, I wouldn't mind that.
  390. Surma:it should just be implemented by tooling is different.
  391. Surma:Maybe, like you kind of hinted at,
  392. Surma:maybe it is something that the browser also supports.
  393. Surma:Like, why shouldn't the browser bundle a JS Sugar implementation?
  394. Surma:But it's something that is then implemented at a separate layer
  395. Surma:that can be maybe maintained by other people
  396. Surma:or fewer people in the browser,
  397. Surma:and then the lower layer of JS0
  398. Surma:is where all the security-sensitive work happens, for example.
  399. Jake:I wouldn't mind that.
  400. Jake:I think that would be...
  401. Jake:And then, like, you know, once performance issues were identified, then maybe, yes,
  402. Jake:that bit could be brought into, you know, C++, Lansing, whatever.
  403. Surma:And, you know, maybe it would finally allow us to use BindOperator,
  404. Surma:which I know the two of us always wanted and never got,
  405. Surma:and we could just have it.
  406. Surma:It's interesting to me because, like,
  407. Surma:I think we both have often said, like,
  408. Surma:JavaScript, like we've said a couple times now as well,
  409. Surma:like, people who don't bundle or don't use any processing,
  410. Surma:just, they leave performance on the ground.
  411. Jake:Yeah, and I agree, and I still say that there is, like, an implementation
  412. Surma:Like, it's free performance, free file size
  413. Surma:that they could have by just running a bundler or a minifier.
  414. Surma:Nobody expects you to write Rust or C++ without running a compiler.
  415. Surma:Why should JavaScript be different?
  416. Surma:Especially because JavaScript is so special
  417. Surma:as being on a streaming platform
  418. Surma:where file size matters oh so much
  419. Surma:compared to all the other languages
  420. Surma:where on almost any native format,
  421. Surma:file size doesn't really matter.
  422. Jake:of this, which I like, which is, like, TypeScript is brought into it, and then that gets sort
  423. Jake:of more scrutiny, I guess, more careful development.
  424. Jake:Maybe some of the mistakes TypeScript has made in the past are less likely to happen
  425. Jake:in the future.
  426. Surma:Yeah.
  427. Jake:It's not just one company in control of it.
  428. Jake:Like, that all sounds good, but then I think the reason I feel icky about it is the ghost
  429. Jake:of IE6, you know, is still there, and this was a time where, like, you know, Microsoft
  430. Jake:dominated the browser space, and they just stopped, because they didn't have to do any
  431. Jake:more work.
  432. Jake:And whereas this is a different shape, because, you know, the other browsers are still there,
  433. Jake:but yeah, it feels like they're all shaking hands and going, well, wouldn't our lives
  434. Jake:easier if we just all, you know, didn't bother anymore?
  435. Jake:Like, we all, like, it's, yeah, we all just colluded just to say, we'll stop it.
  436. Surma:Yeah.
  437. Surma:But, I mean, that's not really what is being said, right?
  438. Surma:Let's think.
  439. Surma:I think they said something that language would evolve
  440. Surma:is just about they would focus on capabilities.
  441. Jake:No, and that's two extremes of implementation of this, right?
  442. Jake:And even with the best of intents now, it's not necessarily where it will land.
  443. Surma:Yeah.
  444. Jake:Like, so another thing that I'm reminded of is, feels like I'm just, like, shitting on
  445. Surma:Yeah.
  446. Jake:Microsoft constantly, but it is another example here, is when Microsoft dropped its engine,
  447. Jake:and they said, like, well, the great thing about us dropping our engine and getting Chromium
  448. Jake:instead, it's like, we can all now work on Chromium, which was genuinely, I believe,
  449. Jake:the intent at the time.
  450. Jake:But then people higher up in the company went, wait a minute, we don't have to.
  451. Surma:Yeah.
  452. Jake:So because Google will do it.
  453. Jake:So we can do, we do other things.
  454. Jake:And I worry that with this agreement in place, that JavaScript now doesn't have to have any
  455. Surma:And you know what?
  456. Jake:new features implemented by browser engineers.
  457. Jake:Yeah, but we're going to work super hard on the other stuff.
  458. Jake:Someone higher up at Google is going, well, the ads team could use some more engineers.
  459. Surma:I think that it's at the very least a valid concern, right?
  460. Surma:Like for me, there was also the parallel.
  461. Surma:If now J0 is kind of like a compile target, is it just a stepping stone that we just
  462. Surma:compile JavaScript to Wasm at some point?
  463. Surma:I mean, Wasm is currently a really shitty target for dynamically typed languages.
  464. Surma:Like, it's just not very good.
  465. Surma:Like with WasmGC, it's a step in the right direction, but really, like, it's still not
  466. Jake:Flutter, as well, right, Flutter, it's just like, well, we'll just ship our own engine.
  467. Surma:good for dynamic typing.
  468. Surma:But at the same time, like, maybe that is something that at some point would happen
  469. Surma:that we're like, no, just don't, we don't choose a language anymore.
  470. Surma:All the processing, compiling, transpiling happens outside the browser, and you just
  471. Surma:ship one binary format to us, which I don't know, that could happen.
  472. Surma:That's kind of how phones work, right, with, yeah.
  473. Jake:Today, I should try them again, because I've never had a great experience with Salesforce,
  474. Surma:One other thing that people did flag is like, they were worried about the debugging experience.
  475. Surma:And I'm like, I mean, we have source maps, and as much as I do not like them, they work
  476. Surma:pretty reliably nowadays.
  477. Surma:Like I'm always impressed that...
  478. Surma:It's like recently, whenever I built stuff with Vite, I stepped through my TypeScript
  479. Jake:but that might be my fault.
  480. Surma:code.
  481. Surma:But I agree, like, I have the same gut feeling, I was like, but they're not robust, are they?
  482. Surma:But then I keep thinking as well, you know, like, no engineer working on systems stuff
  483. Surma:steps through Assembler, they step through their C++, C, or Rust code.
  484. Surma:So this problem has been solved, and maybe source maps just aren't the right solution
  485. Surma:or the right enough solution, and we just need to, you know, learn more from them.
  486. Surma:Like I'm talking about, like, I know a lot about this, but I think this is a problem
  487. Jake:That's fair, you've made an annoyingly good point.
  488. Surma:that is solvable because it has been solved for all those compiled languages.
  489. Surma:Like you can step through your C++ code and inspect the values, even though what is actually
  490. Surma:being executed is machine code on your processor.
  491. Surma:So why should JavaScript to JavaScript be suddenly so much harder?
  492. Surma:But clearly, it is not at the point where we feel confident about that.
  493. Surma:So that is work that also would have to be done.
  494. Surma:So again, something to just be mindful of, like, it's still fair to be concerned about
  495. Surma:that.
  496. Surma:So that was effectively the rundown of J0.
  497. Surma:I think it's not an official proposal in the sense that there is, like, a repository, like,
  498. Surma:for all other proposals.
  499. Surma:I'm assuming something like this may come along at some point, stage 0, I suppose, because
  500. Surma:like I said, like, it was only talked about in TC39 as, like, a discussion.
  501. Jake:Well, that would have to change.
  502. Surma:And I guess we'll keep an eye on it, what this means for engines, for browsers, and
  503. Surma:also for tooling authors.
  504. Surma:Because this is, I think, for me, the biggest unknown, what it means to suddenly put more
  505. Surma:tooling people at the table at TC39, which I'm not even sure, like, you can't join as
  506. Surma:a single person.
  507. Surma:You have to have a company sponsor you, I think.
  508. Jake:If they're kicking the can down to, like, you know.
  509. Surma:Yeah, I, for example, yeah, like, I know that sometimes, like, some people are individuals
  510. Surma:and join TC39 as invited experts, like, Guy Bedford is one of these people who just has
  511. Surma:done, actually, a lot of proposals there.
  512. Surma:I mean, I don't know, now I'm claiming, like, he's an invited expert and not work, not coming
  513. Surma:sponsored by a company, but it is definitely possible.
  514. Surma:But I think you're right.
  515. Surma:I guess one of the things that probably should be revisited if now tooling people who are
  516. Surma:often just, like, open source volunteers are more or less forced to participate in this.
  517. Jake:Hm.
  518. Surma:And I hope that also then they would not be treated as, like, a second class member
  519. Surma:of the board.
  520. Surma:Because I don't know, like, you know, is now J0 the lead crew and then Jsugar the just
  521. Surma:desugaring code?
  522. Jake:I can see that happening.
  523. Surma:And of course, you know, another person also was saying, how is this preventing from just
  524. Jake:Yeah.
  525. Jake:It's interesting because it's going to be, like you were saying before, that they, you
  526. Surma:repeating the same mistakes?
  527. Surma:Like, how do we not just end up with another intermediate layer before we then have to
  528. Surma:start migrating features from Jsugar to Js0 for performance reasons, and we just basically
  529. Surma:end up in the same spot just with an even slower process?
  530. Surma:That also was quite interesting.
  531. Surma:So many things to think about.
  532. Surma:But like I said, it's an early proposal.
  533. Surma:So we have to have to just follow along and see what happens to our beloved JavaScript.
  534. Jake:know, we've made async iterators, but no one uses them.
  535. Jake:It's actually going to be harder to measure which of these JS sugar features are being
  536. Surma:On the scale of zero to bat with nails in it, you never know.
  537. Jake:used.
  538. Jake:Like you could look on npm for downloads of the package, but you don't know which of the
  539. Jake:features within it are being used, right, unless they have a use count, but no one would
  540. Jake:want that.
  541. Jake:So, okay.
  542. Jake:Yeah.
  543. Jake:I am, I am worried about this whole thing, but I'm not like, I'm not pitchfork level.
  544. Jake:I'm kind of interested to see where it goes.
  545. Jake:Yeah, I've got the, I've got a pitchfork on order, just in case.
  546. Surma:The right to bear pitchforks.
  547. Surma:I will definitely put links to the slide deck and any other resources that I used.
  548. Surma:If I did get anything wrong, I will put notes in the notes.
  549. Surma:And oh, yeah, because I built Wasmphobia, where I learned about how source maps work.
  550. Jake:You also did a good episode on source maps in general, which I think goes through some
  551. Jake:of the issues that we've had with them.
  552. Jake:Amazing.
  553. Surma:Yeah, we're going to link to that as well.
  554. Surma:Let's plug our own stuff.
  555. Jake:Bye!
  556. Surma:It's always great.
  557. Surma:Almost another 40 minutes.
  558. Surma:Oh, my God.
  559. Jake:All right.
  560. Surma:I think people might be very tired of me now.
  561. Surma:So I think I should not waste any more time and just say the only thing that is left to
  562. Surma:say at this point, which is happy next time.
  563. Jake:That was good.
  564. Jake:
  1. New View Transition Stuff

    New View Transition Stuff

    49mins
  2. TC39 Roundup Drama Edition Part II: JS0 and JSSugar

    TC39 Roundup Drama Edition Part II: JS0 and JSSugar

    31mins
  3. TC39 Roundup Drama Edition Part I: Shared Structs

    TC39 Roundup Drama Edition Part I: Shared Structs

    30mins
  4. More build tools: Nix

    More build tools: Nix

    41mins
  5. The new stylable <select> element

    The new stylable <select> element

    45mins
  6. Chrome's new LLM AI API OMG

    Chrome's new LLM AI API OMG

    38mins
  7. Chrome’s secretly installed extensions

    Chrome’s secretly installed extensions

    29mins
  8. Are web components worth it?

    Are web components worth it?

    43mins
  9. Why Source Maps don’t always work

    Why Source Maps don’t always work

    42mins
  10. Putting React In The Browser

    Putting React In The Browser

    43mins
  11. Canvas-based Web Apps

    Canvas-based Web Apps

    46mins
  12. The Apple PWA Ban

    The Apple PWA Ban

    51mins
  13. TC39 Roundup and Bevy’s ECS

    TC39 Roundup and Bevy’s ECS

    1h20mins
  14. The Big Build Bool Bonanaza II

    The Big Build Bool Bonanaza II

    1h18mins
  15. WebGPU and Browser Ideologies

    WebGPU and Browser Ideologies

    1h18mins
  16. From the Archive — Changing jobs, Deno, and optimizing animations

    From the Archive — Changing jobs, Deno, and optimizing animations

    57mins