Kotlin/Wasm with Zalim Bashorov - WasmAssembly Podcast

[00:05] Welcome to Basm Assembly episode 17. After I had Ömer and Martin from Flutter's Dart team on the show in episode 14, I have this time Salim Basharoff from Kotlin's team at JetBrains. Both teams, among other platforms, also target the web by compiling Dart or Kotlin to WebAssembly. [00:30] on the show today. Do you want to just very quickly introduce who you are, what you do? Hi, Thomas. Hi, everyone. Thank you for having me. So about me, it's a good question. [00:45] I start this way. For folks in Kotlin community, I probably like recognizable as a WebAssembly guy. [01:00] I'm a Kotlin person or someone quite often talking, asking here and there about TwasmGC and exception handling support. Yeah, that's me. Jokes aside, I'm working on Kotlin project for... [01:18] edged brains for quite a while i think way way before 1.0 even before when language become default on android for example uh [01:30] Last five, six years, I'm leading Kotlin/WASM initiative inside the Kotlin project. It's like about everything actually related to Kotlin and WebAssembly. First of all, from 2 Chain site, compiling Kotlin to WebAssembly, but it's not limited by this, but like

[01:53] For myself, I think I responsible for whole user experiences. [01:58] like inside the debug experience inside browser inside the d everything of course it's it's not done like everything is done but only by me uh face uh team behind behind all these uh works uh and i highly grateful to the team so you joined uh jet brands in 2012 i think according to your [02:28] island somewhere in Russia, I think, just like Java, which is kind of nice. We will talk about the JVM a little bit later. But now I think you live in Amsterdam for some years now. [02:39] yeah that's correct like uh i moved with my family like five five almost five years ago to netherlands and we quite enjoy being here [02:51] Hmm. So talking about Kotlin first, so Java, C++, JavaScript, PHP, all those languages are... [03:00] language is that as a computer science student, typically at some point in your career, you write a "Hello World!" in. Kotlin is a little bit more niche. Maybe some, like the younger folks, will more likely have touched it. But like for me, like I finished my studies, I guess, before Kotlin even existed. Looking at some recent Stack Overflow survey data, it's the 15th most popular technology.

[03:28] If you go to kotlinlang.org, Kotlin is introduced as concise, multi-platform, fun. So I'm intrigued by this. Can you just very briefly for someone who doesn't know what Kotlin is, explain what is concise, what is multi-platform, and what is fun about Kotlin? [03:45] Yeah, thank you for the question. [03:49] So speaking about niche, I think it's quite big niche already. Like, I'm not sure if it's [03:55] uh or the niche uh anyway yeah about concise multiplied from fun thing uh yeah uh concise [04:05] Yeah, you know, Kotlin is modern program language. It was started in 2010s and we just had [04:17] opportunity to [04:20] So, to start most of things from beginning and keep in mind some mistakes done before other language. Not only mistakes actually, but mostly I think we focused on taking right things from different languages. [04:43] we often honestly say what kind of features from which language we probably take [04:52] it's a it's it's good thing i think in term of concise modern language we we tried to make language

[05:01] you're able to to write waste code for to to explain what you want to do for example gotlin comparing to you know to java for example make more influences more local influences so you don't need to write much types we have some [05:25] Nice features like data classes, which just give you some features what you often need, generating convenient to string representation, convenient copy of your classes. You need just to add one modifier data to your class for that. [05:55] bit less, but get more. [06:00] places more, you know. Yeah, about about multi-platform thing, [06:07] uh in in co-op into chain we we have ability to compile in different uh targets we have jvm we have javascript target we have web assembly target we have native target which basically target uh [06:24] to native machine code to different platforms. It is iOS, MacOS, Linux, Windows, everything.

[06:33] in addition to these compilers different compilers would allow you to get binaries for specific environment also on language level we have special features aimed to simplify targeting different platforms aimed to allow you simply share code and make it [06:58] explicit and static like you, you can say this part of my project is shared between all projects. [07:06] At some points you need to access to specific APIs on platform, on JVM, on JS, on iOS for example, and you have such an ability. Unless you need to [07:22] access to a platform specific fee, you can write everything in the common part. [07:27] uh it's it's quite flexible it's supported on language level and on tooling level uh so we try to uh simplify developer work by i know providing [07:42] Mm. [07:43] uh providing diagnostics as soon as possible inside the inside compiler we uh of course in is a tooling company ad company we uh trying to make user experience in it uh as as good as possible uh like providing [08:02] some code generation moving parts between platforms and so on

[08:09] about fun thing uh i i guess some someone from marketing i just had fun with words um [08:17] I'd say here actually two parts about fun. First thing from day one, [08:24] we tried to make a language ecosystem which enjoyable for developers actually we we ourselves use this language for developing our tools for developing internal projects inside company and of course we want to enjoy our tools our language our ecosystem [08:44] It's one part. Another part is in language itself, we have keyword fun used for functions. So every function started from fun. So you can often hear in question community in talks like we have a lot of fun because every function is fun. So I guess some other marketing looked over the... [09:08] Kotlin Hello World, saw the fun and was like, yeah, that's the perfect slogan. Yeah, so when I said niche, obviously this was mostly by my own observation, so me being older than when the classic computer science student started studying. And yeah, as I said, Kotlin did not exist when I was a developer or a student. Obviously also it's an Android thing, [09:34] at least from the beginning. So we will talk about this pretty soon. So yeah, I'm not an Android developer. But like talking about

[09:43] like the old times at Google I/O 2017, so a bunch of years ago, Google announced Kotlin support for Android development. And I remember sitting in the audience in Google I/O 2019, so two years later only, where Google announced that Android was not just getting Kotlin support, but that Kotlin actually was now the preferred way to develop Android applications, which is, yeah, to me a big [10:13] audience like wait what even is Kotlin was there something and the audience was all going like crazy in a positive sense I think few announcements at that I.O. got more applause than that particular one so that's huge Android Studio is based on JetBrains internally so I think that's also some of the reasons why there was this connection and you said you internally also use Kotlin so you eat [10:43] something that a lot of companies including google do and recommend so if you have your own engineers don't like it how should the rest of the world like it so i think that makes a lot of sense so you've been as i said with jetbrains since 2012 so long long time ago um can you just explain a little how this transition went to how kotlin became from being programming languages that

[11:13] way to build Android applications. [11:16] For sure, both of these announcements in 2017 and 2019 was a huge milestone for the Kotlin community and [11:29] I'd say for Android community as well. [11:33] and it's uh definitely uh give like uh [11:38] it's really accelerated the Quatlin growth. How it felt at that time, [11:47] I... [11:48] Actually, myself wasn't a lot involved in these events, but yeah, let me try to remember things. For me, I think the most excited thing was the first announcement in 2017, when Kotlin was officially become a supported language for Android development. [12:16] it was for actually for jet brains for kotlin team it was quite surprising i mean [12:23] We. [12:25] we we we got this information like [12:28] I know about one, two months before announcement itself. Yeah, I guess because like there was some [12:39] discussions inside Google before. But yeah, why something like two months before this event, they contact to our project lead at that time, Andre and CEO of company, Max Raffirve and they are very

[12:57] discussed that i think there was a lot of discussions and yeah at the end they figure out how to do that uh google at jetbrains arranged the kotlin foundation and yeah i i remember first time we when we get this information one two months before uh uh our um [13:22] uh andre and mark's like [13:26] uh gathered whole team uh to to say something no one have any idea what's going on uh and yeah uh they shared about uh that situation uh what face some discussions around it it's not finalized it yet and it should be uh like we we shouldn't share it outside the project uh coaching team [13:56] By the time when announcement happened itself, I remember we sat in event space, the whole team, and watching this keynote waiting for the right time. It was, yeah. [14:13] I'm quite excited, the feeling, yeah. [14:17] next uh next milestone in 2019 [14:21] i think from point of view uh like from internal point of view it was it was like more or less like

[14:31] expected movement is next step because like since the first announcement and [14:37] I think way before, actually. [14:40] for folks from Android community. Some of some of folks actually started using Kotlin for Android development even before Google said that. And one of the reason why Google decided, I think, was there was some push from community from Android developers as well. And after this first announcement, it just opened the door for Android developers. Like they [15:08] can use gotlin without a feeling something will happen like i know at some point google say no we don't want this language [15:20] Yeah. [15:21] I think in 2019 at the same time around this same time Google folks Android team started working on Compose, Jetpack Compose UI framework which of course use Kotlin so gradually Google Android team [15:51] you [15:52] they officially stated like everything in Android is Kotlin first. [15:57] Yeah, that's fascinating. Must have been a great moment for the team to be in that tech room and be in the virtual audience of the event and be like, "Yes, that's my language. That's what I build every day." So very cool. So Kotlin mainly targets the JBM, but also compiles to JavaScript. So there's kotlin/javascript. So for example, you can build front-end applications using React with

[16:27] via LLVM. So for example, for iOS apps, they can share business logic with Android apps by compiling the business logic for those native platforms. But now there's also beta support for Kotlin, Basm. How did JetBrains decide to support WebAssembly as well? What was the motivation behind that? [16:47] it was long story actually before cotton wasm i worked a lot on gothlin and jays tooling and [16:58] I started following these old stories, I'd say from awesome.js at some point. [17:06] I know in 2015, maybe somewhere around, there was awesome JS mostly aimed to cover compilation of native languages like CC++ things. And [17:22] On official page, they actually had one point what was interested for me. At some point, maybe we had some GC support for managed languages. And yeah, I thought what's happening around SMJS. [17:45] actually like languages like kotlin or other languages compiled to javascript at that point use some similar techniques used inside the awesome js not that much like awesome js used the linear memory relating to memory with buffers we didn't use buffers but we we used some other

[18:15] some similar tricks. [18:19] to get maximum performance, to give JavaScript virtual machines more [18:27] type information to help virtual machine basically to infer right types especially when it's about uh [18:35] numbers about I32 or something else. [18:42] at some point uh you know web assembly is happened and i like continue or following what's happening around uh i like uh [18:55] pushed a bit inside the brains what we need to target web assembly at some point we had prototype with uh quarter native with a little bm cotton native use lvm and we had [19:10] some super early prototype which able to compile and run some simple programs [19:18] uh and yeah it was it it worked on uh wasm 1.0 uh [19:26] But... [19:27] Bye. [19:28] Quotling is a managed language and WebAssembly 1.0 is not quite a good target for managed languages. [19:39] when you have objects what manage it by automatic memory management usually it's called garbage collector also exceptions exception also is

[19:54] something that it's difficult to implement on WebAssembly 1.0. [20:02] it's it's possible for both of these both gc and exception handling but it's impossible to to make it performant uh for both of these cases you need to uh have a shadow stack uh you you always always need some performance overhead to support this shadow stake to manage your uh [20:25] memory which actually inside linear memory but you need to emulate your heap for your [20:34] your objects and [20:39] On some early stages, there was [20:43] point in design documents in WebAssembly like [20:48] post MVP features and one of post MVP features was GC and everyone exception handling. Exception handling was moved quite quickly because it's also required for C++ languages, for C++ actually, and Rust probably. It moved quite quickly. It was supported by browser engines quickly. [21:18] it like exception handling is exception from uh uh proposal process in web assembly because it was for

[21:28] suddenly it was turned on by default way before it become final uh reach final stage uh yeah actually like we we had as web assembly community uh we we still have problem with that kind of problem because we have two exception handling proposals right now uh and browser support both [21:58] and proposal. Back to our story. [22:03] So, and... [22:05] So I followed this whole story and continuously pushed, like we need to target WebAssembly because it's more convenient target because we can get better performance than with JavaScript. Eventually with GC proposal and exception handling, it will be a nice target in long run, like WebAssembly could become [22:32] a new big ecosystem [22:36] and yeah i still believe what web assembly could change how we develop web applications later it turns out it can change how developer developer on server side as well but yeah anyway at some point in [22:53] 2019 i think we finally agreed what these web assembly things moved to my team at that point which mostly was responsible responsible for kotlin js thing and me and

[23:10] Another person from my team started working on it as a 20 person project, but [23:16] Yeah, it's... [23:17] It's hard to heavy lift such a project working on it, only 20% project. And around, I know, one year after this start, with help of our product management manager at that point, Dima, we realized we even need to put more effort to this initiative or otherwise, [23:43] like, [23:44] there is no point to do that and after some discussions fortunately we we get we was allowed to hire i don't remember maybe three more people you know or four something like that and we like [24:00] Of course, hiring takes some time, but I think around 2020, we had a team of four-ish persons, full-time engineers working on Kotlin Wasm. After that, it started going quite fast. We fastly implement everything, support all language features. [24:29] started working on different parts of 2chain. [24:35] Somewhere in parallel, actually in 2020, [24:39] WebAssembly community with big support from Google side, especially with folks from Mozilla. We started actively working on GC proposal. There was a lot of discussions around GC proposal. We had, I know two or three different competing options, how it should be implemented and first,

[25:08] two years probably two something years we spent a lot of time on discussions on prototyping changing here and there. [25:17] but finally after I think [25:21] four years of development to see a proposal was finalized. [25:26] and so far for today it's supported by all major browsers and we are owned by default everywhere. Yeah that's fascinating. There's a lot of things that you touched upon like the two implementations of exception handling. I guess you supported both at one point because it was just state-of-the-art back then. Then you chose to implement only the final one which of course makes sense. [25:56] as one of the core things from the very early days on when you realized, wait, Kotlin is a garbage collected language. It's a managed language. [26:07] the way VASM 1.0 works is not really gonna kill it for us. So I really love how this drove eventually the proposal and made the garbage collection proposal a reality as it is today. So [26:25] Just going one step back, so from a strategic angle for JetBrains, after being the Android language, of course WebAssembly then, as I said, was a great way to also become one of the languages of the web and one of the languages of the server.

[26:55] came around you could compile Kotlin to JavaScript so there was Kotlin JavaScript and you could share business logic that was then on the web compiled to JavaScript for DOM access there is a library Kotlin X browser that sort of just feels like a re-implementation of the DOM APIs but in Kotlin so if you come from the JavaScript side it feels very convenient and yeah very normal and regular [27:25] would be like... [27:26] The learning curve for someone who knows [27:28] Kotlin! [27:30] to learn the DOM APIs is not big. And the other way around, if someone already knows the JavaScript DOM APIs, yeah, it is easy to pick up the Kotlin way of doing DOM just because you have the background. So I guess this is like the super early way of programming with Kotlin for the web. [27:48] Did you have any particular user in mind for that way of programming? And we'll talk about the modern way in the next question. [27:55] Yeah, first of all, Kotlinx browser, [27:58] actually is not about not only about dome api uh it has decorations for [28:06] like many browser apis i can say about all browser guys because browser api evolving quickly yeah it's hard to [28:17] yeah uh to keep it up to date uh but yeah anyway it's it's really about browser api it's not limited by uh dom apis uh

[28:27] But yeah, of course, a big part of this API service related to DOM API. You should think about this library not like the implementation of all these things, but it's quite [28:45] lightweight to [28:48] a library aimed to just provide the same API available inside browsers. [28:55] it's somehow similar to the decorations in typescript details files or you know h files with just decorations in cc++ world so we have same thing we call it external decorations and yeah this library mostly contain uh [29:15] External declarations, use cases. First of all, use cases is get access to different browser APIs independently how you build your UI. Anyway, you need to access Fetch API, for example, to GPU, maybe something else, notifications space. A lot of useful APIs inside browsers nowadays making possible [29:45] to build [29:46] almost any application you need. Rarely you miss some API that's not available on browsers, what you need to build desktop applications. Actually, like many things you need for

[30:03] usual stop applications is available as browser apis for dom things it's [30:11] It's quite useful, still quite useful. Sometimes folks need to build lightweight UI and using DOM nodes in this case is the right choice. It's [30:28] It has a better integration with browser when you use DOM API. You have better accessibility, you have better [30:36] integration with browser plugins, for example. [30:41] in term of [30:43] memory consumption, maybe it's [30:46] a bit better using DOM API. [30:49] Yeah, it's more about lightweight [30:53] building lightweight ui but on other side you need to put more effort you need to write more code you need to manage your dom nodes so it's [31:07] Mike? [31:07] it's always is trade-offs you [31:10] You get something, but you pay something for that. Which brings us into the maybe more convenient way of building graphical user interfaces, which is Kotlin Multiplatform. So for Android, I think there is the product called Compose, where you essentially describe how your user interface should look like. And then you have the Android Views and so on.

[31:40] Kotlin Vasm where you can build web applications with Kotlin that use Kotlin Multiplatform as the single code base where you just target multiple platforms like Windows, like Linux, the web, obviously Android, iOS, all with the same code base, all with the same UI code as well that you create in Compose Multiplatform. And I think internally it's based on Jetpack Compose. [32:07] then uses a Kotlin compiler plugin to transform those composable functions into UI elements. [32:14] How does it work? [32:16] all those different platforms, iOS, Windows, Linux, web, all of them have different graphics primitives. But like, how does it work? How does it achieve this? Is there any limitations that you need to live with? [32:31] go deep inside compose multi-platform actually we have two two parts here uh cortely multi-platform and compose multi-platform it's different parts you can think about it how different layers so we have uh cortely multi-platform it's super core things uh we have some support about multi-platform on language level we have support special support on uh tooling level [32:59] And at this point. [33:01] when we speak about Codefuel Multiplatform, about sharing any code, not only about UI. You can share any code. At this point, some of users actually decide not to share UI code, but share only business logic. And here's the point where you can do that. We have some language features with Expectaxe Show, for example, special declarations.

[33:31] allowing you to [33:34] but, [33:35] to draw a border between where is common parts, where is platform parts, and you as developer decide when you can write everything, most of things in a common part. When you need something specific for your platform, you can do this in platform parts of your project. [33:59] Um... [34:01] and uh compose much platform uh yes you correct is built uh uh basically [34:08] on top of Jetpack Compose, which originally was developed for Android. It is a modern UI framework. The way you describe your UI, a decorative way, [34:24] It's. [34:26] it somehow calls how it's done in React, in Angular, in modern UI frameworks, all of them trying to give you [34:39] and decorative way to describe your UI. And underhood compose trying [34:48] You can think about it like a huge state machine. It's trying to understand your dependencies, data dependencies, UI dependencies, [34:59] When something in your state is changed, this framework on the hood trying to minimize amount of work, what should be done to update your UI.

[35:11] at some point uh folks it budget brains decided to commonize this jetpack compose and ported it to different platforms to uh desktop platforms to ios to web so it it allow you to write uh [35:30] your ui quote once and basically getting uh [35:37] More always pixel perfect UI, same UI on different platforms with the same code base. [35:47] On... [35:48] technical point of view how it works on the lowest level you asked about graphics things uh [35:58] I think, [35:59] most on all platforms it it rely on skia uh [36:05] it could be like a bit different skier but you know on android uh at some point uh graphic rings is done with skier for desktop for [36:17] It's on Compose Multi-platform site. We actually have a library, [36:23] called Tsukika, it's a [36:25] Cortlandized API on top of Skia. [36:29] Inside Compose Multiplatform we use this SKICA library. [36:34] So for all platforms, actually, yeah, for desktop, for iOS, for web, for web, it's a bit funny, probably, because we bring our skier library.

[36:50] and at some level inside browser they actually also use here but it's uh hidden uh [36:59] like behind the browser api so we we don't have direct access to this skier unfortunately and yeah we have like uh at a higher higher level on user level our version of skier which draw on top of canvas or on top of webgl canvas [37:20] Thank you. [37:22] yeah it that's how it works on lowest level on graphic level after that like phase [37:29] uh different level of obstructions inside the composer platform uh aimed to like make it uh flexible make make it uh [37:40] easy to change some parts [37:43] So taking a step back, like if you recall, there was a language that had this write once run anywhere kind of promise, Java obviously. And for Java applications that had graphical user interfaces, [37:59] you would, I think in the early days, use something called AWT, abstract window, windowing toolkit, something. And it was exactly not what you said. It was not pixel perfect. It always had this local flavor. So a Windows button would look like a Windows button. Linux button would have a smell of Linux and so on. And then I think later on they developed swing, which sort of was like an abstraction layer on top of the abstract, like window toolkit idea.

[38:29] where at least everything would look the same. So you've got something that looked and felt exactly the same on all platforms. But conceptually, if you created a button in your code, you still got a button at the operating system level. But what you were saying is that on all the platforms now, you essentially paint pixels on a canvas. So there's an Android kind of canvas. There's the Windows canvas, Linux canvas. On web, we actually have a canvas element and so on. [38:59] this... [39:00] representation of the [39:03] operating system of something being a button something being whatever a text field you just jump straight into pixels is that a correct yeah [39:13] interpretation of what you were saying. [39:15] Yeah, that's correct. [39:18] Yeah, comparing to our own UI frameworks we had in Java or in other fields, actually, [39:28] I think biggest difference [39:30] from user point of view yeah when i say user often i mean developers so yeah from developers point of view main difference is decorative versus imperative uh old frameworks mostly imperative and modern ones trying to be decorative because it simplify uh it's [39:53] Yeah, highly simplified. [39:57] a work of developers who built with UIs.

[40:01] Um, [40:02] Of course, when we paint on top of canvas, when you work with [40:08] uh with pixels it it has drawbacks and main drawback is uh like accessibility like things uh and inside the frameworks like compose much quite from using uh pixels uh [40:26] like we need to do something special for accessibility. And inside ComposeMod platform, we actually do. We're trying to fix accessibility things inside browser, actually on all platforms. We need to do something on all platforms, on Android, desktop, everywhere. But accessibility is quite important things, you know. [40:56] Aside from accessibility API, we're also trying to emulate something with DOM elements, with normal browser input elements to get [41:10] the best experience what we can provide [41:14] for a final user. There's a new web API proposal, I think it's called Canvas Elements, where you sort of can render HTML elements onto a canvas. So if you are able to translate your [41:27] Kotlin kind of concept of a button to something that would translate into the web API's concept of a button, this would likely be an API that would help you a lot because then you get all the browser machinery that it already has in place for implementing, I don't know, accessibility behavior of buttons of all the native HTML elements essentially for free, I think.

[41:51] For surely following this new proposal allowing you [41:56] to put your HTML elements inside Canvas. And we have some ideas how it could be useful for us. [42:04] about [42:06] like mapping our compose components directly to similar components. It's a tricky question because [42:17] like [42:18] for some specific elements like button we probably can't do that there could be questions around how sterilize them and compose [42:34] provide to developers [42:37] quite [42:38] flexible API so they can customize everything highly so I guess not everything could be mapped directly so at some point maybe quite often we need to map everything to canvas because [42:56] I know in general, yeah. [43:00] Compose developer can draw some tricky shape button with tricky shape. And yeah, we need to support everything possible in terms of Compose API. [43:16] But anyway, having DOM elements right inside the...

[43:22] Canvas can simplify some accessibility-related things, I believe. Also, we have another case when we need to actually embedded some real DOM part inside Canvas. [43:39] you know, like a piece of [43:42] some site or some component written in React or so on. In these cases, definitely it will help us. [43:51] Hmm. So this is the first proposal that we talked about that is kind of new. In the past, you mentioned before, garbage collection was a super important proposal. Exception handling was an important proposal for Kotlin. But that's, of course, an ever moving space of new proposals. Can you tell us a little more about new proposals you were excited about in the world of Kotlin VASM? That's a great question. [44:15] Uh-huh. [44:16] I actually divide [44:19] these proposals in two groups. [44:23] like, uh, [44:25] first group is about [44:29] making WebAssembly first class citizen inside browser, [44:33] It's a. [44:35] uh something something what i think personally quite important and in this term uh we following and we quite support [44:45] as much as possible on our side with experimenting or just promoting it. A few proposals. Firstly, ESM integration, which allows you to import WebAssembly binaries directly inside your JavaScript, maybe between different WebAssembly binaries. So just ESM as an ECMAScript module, just for people

[45:15] So ESM is ECMAS BrickScript modules. [45:18] Yeah. [45:20] It also is addition to the ESM integration proposal, make your application somehow more secure because right now when you instantiate WebAssembly, you basically download some binaries and instantiate and web browser web browsers or web engines. [45:39] can't guarantee this binary was wasn't modified way this binary where where from it come and so on and in some environments because of this problem in some environments browsers restrict web assembly usage treat them [45:59] more unsafe, for example, for developing browser extensions. [46:05] you need to put some in your... [46:10] description of your extension. What unsafe something about your extension, because API, WebAssembly API can't guarantee [46:25] like where from is it's come uh basically it's like a secure surface uh security surface uh uh for browsers so they treat right now without the assignment integration they treat browser web assembly apis is less unsafe um web assembly itself of course is run inside sandboxing but uh

[46:48] like a base, different level of safety. [46:52] next thing what aims to improve experience and i think i feel i think could make [47:03] WebAssembly, much more first-class citizen, is component model, component model, [47:10] Originally, it was called something like interface types and aimed to provide typed API for browser APIs, typed access to browser APIs. [47:25] At some point, it was transformed to something more generic or bigger component model, which also used. Right now, it's mostly used outside of browser, honestly. [47:40] I believe inside browser we need something like that, maybe a component model, maybe something similar, but we need to have direct access without any JavaScript code involved direct access to browser APIs and. [47:56] As next stage, browser API should be designed with [48:01] with WebAssembly and JavaScript in mind, in contrast to modern world when browser APIs nowadays designed with JavaScript, only JavaScript in mind, like we have only JavaScript inside the browsers. So

[48:21] Yeah, recently, last week, we have Web SMDCG offline meeting and one off topic, I'd say hot topic was component model and its usage. [48:36] uh inside browsers i think this time it was quite positive we of course [48:42] We didn't get promises from browser vendors, it will be supported, but at least there was no rejections. So probably we're going to discuss it more and who knows, maybe at some point we'll get component model support right inside browser without any shim. [49:03] uh yeah these two things about how make web assembly first class it's the real first class is an inside browser uh another thing [49:13] group of proposals what i want to mention is [49:18] more about how [49:21] make WebAssembly ecosystem WebAssembly as the target inside browser especially. [49:28] Um, [49:29] better choice in some sense. [49:32] And two proposals here is stack switching and shared everything. I believe we've shared everything we can make developing [49:45] browser applications more enjoyable and we can move

[49:52] browser applications on next stage. Nowadays, we have a lot of browser applications, and we've shared everything proposal. [50:02] it will be possible to do much more things simpler, [50:07] at some sense [50:09] i think uh [50:11] we've shared everything with my with multi-phrasing with true multi-phrasing the platform could become something similar to jvm without any compromises you can use threads you can afford some works outside your main main worker and yeah it i believe it could highly improve [50:41] better uh with freezes in uh uifred which is uh at the end it's a penny penny [50:49] It will be benefit for final users, for every users around the world. [50:55] about text switching why i i think is quite useful [51:01] two reasons actually. Stake switching, I believe it will help in terms of size, languages who have [51:08] features like a single weight or some simple similar things. In Kotlin we have [51:15] a similar thing. We call it suspend functions, we have coroutines library, but for any language, I believe with stake switching we can get

[51:24] Small binaries, especially in applications, highly use, I think, await things. [51:32] Also, I believe state switching could improve performance for same things. So when you use highly, I think, await constructions in your program because [51:45] what what usually right now without stack switching uh compilers to chains to is transforming [51:52] this [51:54] suspendable functions in state machine so you you have a lot of small state machines here and where every function is small state machine uh and generate a lot of code of course [52:06] Also, [52:08] it this state machine is it's it's messy actually like you have here there some some code of blocks you have big four loop probably big switch and for virtual machines for compilers it's kind of code what is not quite optimizable often inside this function you have something [52:38] with, uh, [52:39] uh [52:40] from point of view of compiler you kind of have whoops with uh not one entry point but more than one entry points and rarely these compilers who try to optimize such whoops they just give up and let it go as this uh and you can imagine like you can have uh

[53:03] a lot of such irreducible loops uh high [53:07] hardly optimizable functions around it how how it works nowadays when you have something like i sent to wait inside your program when you use a syncify or a similar technique uh what's tech switching should allow us [53:23] in in many cases in most cases our functions will stay the same without splitting in state machine so it it'll be like the same uh functions a quite good structural uh program uh and such programs yeah will be optimized quite well inside virtual machines inside the ahead of time compilers so [53:53] With state switching, basically, we will get at the same time smaller binaries and binaries what could be optimized easily for virtual machines for compilers. Yeah, I think these four proposals is my top list for now. Yeah, I love it. I love how all of this is driven by the desire to make things better, smaller binaries, faster running applications. All of this sounds highly, of course, [54:23] desirable from a user point of view. So, [54:26] Maybe we talked about WebAssembly on the client, WebAssembly running in web applications, where sometimes all of this can be a bottleneck. But one thing we didn't mention, but where Kotlin is also a big thing now, is Kotlin on the server. So from my understanding, you have, as I said, access to the component model. You have support for VASI, the WebAssembly system interface.

[54:56] Everland. [54:57] Yeah, server-side using outside of browser and specifically on server-side is one of things that we're considering for Kotlin WISM. [55:09] it's not that big [55:11] Honestly, right now, we're more focused on browser, but we still [55:17] following what's happening outside of browser. Right now, [55:23] For outside of browser usages, [55:25] We support YC preview one or 0.1. Yeah, it's same thing. And we have... [55:37] early prototype with component model which is basically required for next versions of YZ, preview 2 and preview 3 I think will come soon, Sainish. [55:53] and [55:54] Yeah, outside of browser, [55:57] It's. [55:58] it's on on our table and we we're going to put more effort on the component model [56:05] uh we we want to finalize some design of component model what we have and make it available from toolchain at the beginning it will probably will be some kind of experimental but yeah we we want to to give it to users to allow them doing some cool stops on their side yeah

[56:35] gets get their hands dirty, wants to get cracking with Kotlin. Where would they start? Like obviously there's JetBrains IDE as a product. So very likely there's tooling support for Kotlin in JetBrains IDE. But like what is the developer experience? What can developers expect? [56:55] Of course, we have many ways to getting start with Kotlin Wasm. [57:01] I'd say if you want to remember only one thing, just remember one link, Kotl.in/wasm, and you can find everything there. But yeah, I can... [57:15] and try to elaborate what kind of options we have. [57:19] Simplest way to try something is our playground. We have play.cotlin.org where you can write inside browser, write some code, you can run it. Even there we can have... [57:36] support for Compose March platform. So you can run code snippet written for Compose March platform. [57:46] and basically get some UI [57:50] right inside browser and of course it's powered by Kotlin Wazen. [57:56] uh next things is next thing is of course id we have uh [58:02] Uh, [58:03] support inside ADE, you can create your project inside ADE.

[58:10] in inside the de you you'll get uh maximum uh the best experience what we can provide now so you you can start you you basically start from wizard create some project and you have uh editor with refactorings everything uh navigation and so on everything you can expect from modern 80 everything [58:40] as well. [58:42] Inside IDE, we have debug capability. You can run your browser application right from your IDE. It will be run in a separate browser. And you can debug this application run inside IDE. Inside IDE, we're trying to... [59:02] provide you the best experience in term of debugging when you stop somewhere you you see variable views we we put a lot of effort to make this variable view to be nice to show your uh [59:19] some objects [59:21] not how it's represented or low level in web assembly like structures nested structures and so on we're trying to show users [59:32] some high-level view in terms of Kotlin. [59:37] it's we try to make it cool as much as possible close to gvm experience uh because we have a lot of experience with jvm we have you know a great development experience inside gvm for java and kotlin uh and yeah we're trying to mapping all these things to other platforms including web assembly

[59:58] For example, for lists, for collections, maps, sites, we're trying to build a special view inside this variable view so you easily work with all these things. [1:00:12] in terms of debugging some of improvements we also try to apply to browsers uh uh [1:00:21] uh [1:00:21] unless it's possible. [1:00:24] like better variable view, better names, better stack traces. We do our best to provide some similar experience inside browsers. Some things like better variable view require to own [1:00:40] some options in the dev tools because face custom formatters thing but in dev tools in chrome based browsers it's off by default so if you own it you you'll get better representation inside very very few instead of wall level web assembly structures some more high level kotlin [1:01:09] code assistance, things that people expect from modern IDEs. [1:01:14] copilot these kind of things yeah for sure everything ai things in this point don't [1:01:22] directly stick to like kind of project it just worked for any projects yeah mostly a everything worked for you know quotient projects should work for uh web assembly for quality multi-platform as well um

[1:01:41] a side of id [1:01:44] if you for some [1:01:46] any reason you don't want to use the IntelliJ IDEA. You, of course, we have template projects on GitHub. [1:01:53] so you can just call these projects and [1:01:57] start in ATE what you like more. [1:02:03] recently on i think experimental stage we uh announced uh lsp support for gotlin so if you prefer some other id supporting lsp you can take our lsp support official support for gotlin and use it you know vs code theme everywhere anywhere where where lsp supported but [1:02:28] From my point of view, the best experience we have right now is IntelliJ tier, obviously. [1:02:36] It's up to you. Yeah, it makes total sense. So the episode ran quite long already, but I still wanted to ask you one last question about next milestones. So things that you have planned for Kotlin, Kotlin Basm, in the next couple of months, years, maybe... [1:02:54] if you can very briefly just summarize what what you have on the on the line there yeah i'll try to be short here [1:03:00] So recently we moved QuotlinWasm and ComposeWeb to better. It was like in September. And obvious next step for us is make it stable.

[1:03:14] And [1:03:14] yeah obviously we working on it right now [1:03:18] no specific data but yeah we definitely go in this direction speaking about more specific things aside [1:03:29] uh stable direction uh we of course have different experiments what's going on right now firstly around [1:03:41] shared everything threads uh we uh which we're prototyping on our side on to chain side uh this proposal and uh yeah we're trying to understand how it's going on how it uh work this proposal for kotlin uh [1:04:01] We're trying to help virtual machines. The proposal offers to check to verify some things on proposal. Next proposal, what we... [1:04:12] trying obviously stack switching we are also prototyping stack switching proposal trying to apply it to Kotlin and understand the limitations [1:04:26] At the end, I think both working on these both proposals is good thing for both the Scotland community and the WebAssembly community. [1:04:36] uh another thing [1:04:40] is component model. As I mentioned before, we want to

[1:04:45] to reach a point when component model could be used from [1:04:51] official toolchain not something built from sources and so on how we have right now prototype [1:04:58] So I think, yeah, stable, these three proposals is the main directions. Of course, developer experience, we highly care about developer experience and we work, we continuously work in one developer experience. Exciting, exciting. So I guess we should get you on the show again when Kotlin-Wazen hits the stable milestone. But yeah, you said it's not... [1:05:24] exactly fixed yet when this is going to happen but it is going to happen so looking forward to to this um so good luck and um yeah from what you say you're collaborating very closely with all the proposal authors so i think that's also a promising recipe to success so with that um we are at the end of the show which always means um the two questions vasm but not my first question [1:05:54] any of your streaming devices, what is it that you currently watch or listen to? [1:05:58] i i'd say it's more the most tricky part of this podcast for me so yeah about streaming things um [1:06:06] i'd say i don't watch much or much shows in in streamings uh but i i listen a lot of podcasts i think uh

[1:06:18] obviously wasm assembly is one of thing i think it's right now it's only one focused on web assembly at least it only one i listen regularly there is of course some podcasts not focused on web assembly but with web assembly episodes which i love to listen anyway other other podcasts [1:06:42] None. [1:06:43] um non-verb assembly once i i love to listen uh wall street journal uh tech news just to to be in touch what's happening around in tech i enjoy listening why combinator podcast uh [1:07:02] other uh other podcasts uh talking caution of course based talking kotlin podcast uh from from jetbrains from our developer advocates uh it's uh which is yeah another way to understand how kotlin is used [1:07:19] it's yeah enjoyable i recommend it um what what else [1:07:26] base recently i find out a podcast from egalia uh egalia uh it's [1:07:33] company who contribute a lot to browsers and things around and they have a podcast called egalia chats [1:07:43] um yeah it's also uh one of podcasts i enjoy

[1:07:48] Definitely a good one. Ran by Brian Cardell and Eric Meyer. I'm also a regular listener. Cool. Thank you. If there's one thing that you could local get, as in something that you do, and then global set, as in something that you wish everyone else did, what would that be? And if you want, you can also turn around the question and make it the other way around. [1:08:12] You know, I'm working for JetBrains for quite a long time, and JetBrains is a tooling company [1:08:18] And maybe I have already some [1:08:20] kind of prof deformation. But anyway, I really care about [1:08:26] developer experience and yeah probably if that's the main thing I'd like to to be better in web assembly community especially to to make [1:08:40] to to to put more efforts to to improve uh [1:08:44] experience for [1:08:47] developers who use uh web assembly tool chains it's about everything actually from building applications to delivering debugging uh how to provide better access to browser apis to any apis of all those things yeah i'd like to to make developer experience [1:09:08] beta. [1:09:09] yeah make developing web assembly targeting languages targeting applications enjoyable [1:09:18] Definitely super important. And if then also the user experience is great, I think both sides win. Developer experience is super important. But then, of course, in the end, we're building for users. So if their experience is great, too, everyone is winning. Cool. Thank you, Salim.

[1:09:48] Like where can people reach out? [1:09:50] yeah i have an account in many social networks linkedin plus sky in many places i think in uh [1:10:01] In all these places, [1:10:03] you can find me with my last name bashorov somehow um [1:10:09] And most of relevant links actually on my page at bashorov.com. So yeah, I probably going to bashorov.com is easiest way to find my relevant social links. Someone maybe prefer LinkedIn, another one prefer, you know, [1:10:32] mastodon so i i have everything great but with different level of activities in these networks but yeah if someone sends your message you will react yeah that's great um actually i realized you seem to like short URLs because you managed to uh get yourself sal.im so zalim yeah which is cool and also before you mentioned very briefly cut cutle dot i in which spells kotlin yeah um [1:11:02] im slash vasm, right? So the one URL that people should take away from this episode. And then sal.im. So one is im for Kotlin, and the other is im for Zalim, if you want to reach out. Cool. Or bashrof.com, obviously. Thank you very much, Zalim. I learned a lot. I want to play with the Playground, see some Compose Multiplatform code, and if I can get it up and running. Thank you very much for being here,

[1:11:32] questions and if you out there have something interesting to say about the world of web assembly definitely also reach out i'm always happy to have guests from yeah the wider web assembly ecosystem you can find me just like zillium on essentially all social networks if you search for my handle tomayac so t-o-m-a-y-a-c tomayac definitely you will find me on whatever social [1:12:02] And with that, thanks Salim one last time. And yeah, we will be closing this episode now. Thank you very much for listening. Thank you for watching. Bye-bye.