Nathan Walker, Eduardo Speroni - NativeScript

{/ TAB: SHOW NOTES /} This week we're joined by Nathan Walker and Eduardo Speroni, two members of the NativeScript team. NativeScript is a framework that enables you to use native platform APIs in JavaScript. We talk about the history of NativeScript, the current state of the project, and the future of cross-platform mobile development. - https://nativescript.org/ - https://nativescript.new/ - https://x.com/NativeScript - Nathan Walker - https://x.com/wwwalkerrun - https://github.com/nathanwalker - Eduardo Speroni - https://x.com/eduardosperoni - https://github.com/edusperoni Apply to sponsor the podcast: https://devtools.fm/sponsor Become a paid subscriber our patreon, spotify, or apple podcasts for the ad-free episode. - https://www.patreon.com/devtoolsfm - https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe - https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 - https://www.youtube.com/@devtoolsfm/membership {/ LINKS /} {/ Paste show notes /} {/ TAB: SECTIONS /} [00:00:20] Introduction [00:01:38] What is NativeScript? [00:05:53] Performance and Native Bridging [00:12:26] Ad [00:12:57] Exploring NativeScript Runtimes [00:20:02] NativeScript's Flexibility and Plugin Ecosystem [00:28:09] Framework Integration with NativeScript [00:36:35] CSS in NativeScript: Real or Translated? [00:42:34] Balancing Web and Native Performance [00:45:57] Real-World Examples and Ecosystem [00:48:23] Expanding Platform Support [00:55:27] Advanced Features and Shared Memory [00:58:43] Showcasing the Lighting Console App [01:04:56] Conclusion {/ TAB: TRANSCRIPT /} Episode 107 - Free Nathan: [00:00:00] NativeScript aims to bring native platform development to JavaScript in as natural way as it can. It wants to allow you to do platform things from JavaScript Things like Kotlin, Swift, Objective C, Java. [00:00:20] Introduction Andrew: Hello. Welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew. And this is my cohost, Justin. Justin: Hey, everyone. Uh, we're really excited to have Eduardo Speroni on and Nathan Walker, and we're going to be talking about, uh, A topic that I'm actually really excited about because I heard this, uh, I heard about this about a decade ago and I was like, really, really interested in it. Like played around it a bit in the early days. Justin: So we're going to be talking about native script today. Uh, and it's crazy to me that it's been a decade. I was like going back and like looking at it as like, yeah. You know, I think it was like made in 2014, but really publicly announced in [00:01:00] 2015. Uh, so I was like, yeah. Wow. That's, that's crazy. It's been that long, but I'm, I'm super excited to talk about this. Justin: Um, but before we begin, would you each like to give an intro? Hey, Nathan, why don't you start? Nathan: Sure. Hey, everybody. Nathan Walker. I'm co founder in studio and a member on the working group or technical steering committee with native script and love working around that kind of stuff. So excited. Excited to be here. Eduardo: Uh, and yeah, I'm Eduardo Speroni. Um, uh, also on the TSC and I've been working mostly with, uh, Valor software, but I also like work with Nathan on a few projects. [00:01:38] What is NativeScript? Justin: Awesome. So let's just dive into it with when y'all like to sort of just like describe what is NativeScript and maybe some of our familiar, our listeners are probably familiar with like React Native. Maybe we can kind of compare and contrast with that. Nathan: Yeah, maybe I'll start on that one. I mean, NativeScript aims to bring native platform development to [00:02:00] JavaScript in as natural way as it can. It wants to allow you to do platform things from JavaScript and therefore it sort of brings platform languages to JavaScript. Things like Kotlin, um, Swift, Objective C, Java. Nathan: Um, you can do constructs, you can even use practices and constructs that you would use in Objective C, um, philosophical, uh, structures and, and, um, You know, approaches like delegates, for example, and objective C, you can do those in JavaScript with native script. Um, and really aims to bring the entire JS ecosystem to platform land. Nathan: Um, that comes with a lot of, a lot of things to talk about there. But I think. Maybe in a nutshell, that's what it is. But, uh, along with JavaScript comes all the things you would expect, like web approach, you know, CSS, um, being able to do standard view, templating and markup, uh, marry that with CSS to develop an app. Andrew: [00:03:00] So is it like, is it like a react native where you're like composing native stuff to create an app or like I saw there was CSS in there, or is it like more of a, a web view, but you can hook into the native stuff and then show stuff in a web view? Nathan: React Native and NativeScript have similarities in what you're working with, because you're working with the platform view language. So. You know, a UI view, for example, and UI kit on iOS is something you'd work with, um, through a view construct and react native, um, native script. You'd work with the same thing and say a grid layout or a stack layout. Nathan: Um, there's even talks to maybe bring a singular view like react native to native script. So you're working with the same view level. Uh, between React Native and NativeScript, but that's probably where, um, the similarities end, uh, in terms of the approach because, [00:04:00] um, NativeScript takes more of an approach that you are dealing with the, um, platform kind of as is. Nathan: Um, you tend to work with the platform language as you would when you're in Objective C or Swift. Um, and so you're not having to necessarily go too much in and around, um, the platform maybe sometimes. Eduardo: Yeah. And to just like, uh, expand a bit on that, uh, I need to script like the, the UI layer, you can say, you know, it's all, uh, or like most of it is done directly in JavaScript. So we don't need to get, uh, you know, you don't need to write, uh, native code to build, uh, in UI, even from scratch, you know. Justin: I remember when I discovered NativeScript, around that time, I was still sort of messing around with like Cordova apps. I don't really remember what the state of, I don't think React Native was really much of a thing then, or I wasn't aware of it at all. I don't even think it existed then. Uh, but like, I had been [00:05:00] doing a lot of, uh, Cordova apps and you get to this point where it's like, okay, well now you have to write like, uh, native extensions, like, you know, in the app framework. Justin: Uh, so Cordova for those people haven't heard of it is like a way to just make apps with a web view. That was really kind of all it was, is like package up a website as an app. Um, and the thing about native script that just seemed magic is, you know, Nathan, like you said earlier, you, you kind of generate JavaScript bindings for the entire, the entirety of the native APIs, like everything that you can call, you know, an objective C on iOS or in Java, on Android, you can call with JavaScript and, and that like blew my mind. Justin: It's like, wait, so I can write a JavaScript file that kind of like hooks on different platforms and uses the bare platform primitives? Um. [00:05:53] Performance and Native Bridging Justin: One of my questions that I have that I always wondered is like, Is that really slow? Like [00:06:00] doing the native bridging, you know, this is something that we have a problem with, with like Wasm these days. Justin: It's like the, there is a cost to translating from one data type to the other, like one, you know, the, the bridging costs, but so what's the story with like performance and native script? Nathan: I'll let Ed touch on that in a minute, but, um, maybe I'll comment on one thing, which is that very aspect of it, which is bringing all platform bindings to JavaScript is I think what rightfully so scared people to in the beginning is a bit, uh, a bit, um, maybe ahead of its time at that time. Um, and the thought of doing that, I think, rightfully so scared some people excited some people. Nathan: And so, along with that came some controversy, um, and, you know, there's always controversy around, um, bringing anything innovative out there. And so there was a lot of uncharted territory. Uh, in that. And so, you know, in the 10 years that have spanned by, you know, that approach has been brought to production and a lot of different aspects. Nathan: And so, you know, let's [00:07:00] talk about the performance nature of that. And maybe Ed, if you want to touch on that. Eduardo: Yeah. So a Natescript is like does most things like very, I mean the most optimal things that we can. Right. So for example, when we generate the app, like at build time, we actually generate. So during that build time, which is not like long, it's just like a short build time. We actually generate the whole bindings for the platform, but mostly generate what we call metadata. Eduardo: Right. So we know how to call, uh, like which functions to call dynamically, uh, at build time. And then that becomes like a file, a binary file of like, I don't know, three megabytes or something. It can be a smaller or bigger depending on how you configure it, right? Uh, We generate this small file that is then like directly injected into the binary of your app. Eduardo: So when your app opens, that thing is already loaded into memory, right? So you don't need to like load anything in. It's already there, right? So, uh, uh, makes it, uh, much, uh, faster. To, to access things and, and [00:08:00] find things when we need to. And of course, uh, we do have, uh, essentially like we have a couple of overheads, right? Eduardo: So we have like the overhead on iOS, which is, uh, first, I mean we are, we are using V eight. We are also expanding on other, uh, different, uh, engines as well. Uh, but uh, we are using V eight underneath, and at at least, like most other engines are also using some kind of like c plus plus or, or. Right. Some, some kind of, of, of thing like that. Uh, and what happens is, so we, there's like the, the traditional cost of like going from V8, like JavaScript to C plus plus, which is. Kind of big, but not really. You know, like if you, so I mean, if you can do like, uh, three, I think it was like 3 million ops per second, then like if, uh, I mean 3 million ops per second in JavaScript, pure JavaScript using V eight. Eduardo: And if you like, instead, uh, replace that, uh, JavaScript [00:09:00] operation with like a. Uh, native function call that goes like 2. 5, uh, you know, a million per second. So it's kind of like, it's an actual thing for most part. Um, the heaviest part is usually because, uh, so you're, you're, you're like, you're passing, you know, like you're passing a number and then the function might have received like an int or receive a string and then native script does its best to do the conversion for you. Eduardo: Sometimes, you know, like if you, if you pass a number and the thing, you know, Requires a string. We are just going to like throw an error because like you're trying to call like a different, like a function that doesn't exist. So we'd have to do that. Nathan: I think that's a good, pause, a good a good pause point too, because, you know, if you're working in Swift and you try to pass a string to a function argument that expects a number, you know, you're going to get. Uh, a crash, but more likely your compiler is not going to compile native script, brings the types of the platform. Nathan: So for most API calls, you also are going to get a compile time error. [00:10:00] So, you know, the function signature is actually going to be in TypeScript that it actually accepts, uh, you know, a string and not a number. Um, but for any given purpose, if you were. to pass something into a function that either the types were weak enough that didn't capture you, you're going to get a similar throw that you would get in Swift or Objective C land. Nathan: So your experience working with that language is pretty similar. Eduardo: And I mean, like we are also TypeScript first, right? So, uh, for, uh, as, as well with like generating the metadata, we generate also the types for the metadata. So there is no way for you to, you know, uh, I mean, uh, at least like if you're using TypeScript, you're going to like get, uh, you know, build errors. If you try to. Eduardo: Use, uh, different typings. Uh, but, uh, the other overhead that we have is also like the LibFFI, right? Essentially this is on iOS, right? So LibFFI is what, uh, you know, node uses underneath and like denodes underneath everything. Everyone uses to call, uh, functions that you essentially, uh, you know, are not built into, [00:11:00] right? Eduardo: Uh, eventually when, uh, Apple, uh, allows us to use, uh, JIT, On, uh, you know, uh, on their platform or like on their app store, we should be able to improve that even further by, you know, uh, just pre compiling, uh, a few hot methods that you're using like quite much, right. Uh, but essentially like it's around that we have like a few benchmarks that we've done, uh, comparing like mostly like native, uh, react native and, uh, need to script on like the whole overhead that we take for like each. Eduardo: Each method, right, and it's essentially like, uh, yeah, if your function does, like, very little, uh, and you're calling it quite a lot, then you're going to take, uh, you know, a hit and you're going to feel the hit, but it has to be, like, called, like, quite frequently for, for that to happen, like, thousands of times per second or something, right? Eduardo: Um, All of that on Android, uh, so you have like the other side, which is Android uses the Java native interface. So JNI, and that's a bit slower, right? So, uh, I, on Android, we try to limit a bit [00:12:00] more of like what the calls that you do, right? To, to native, but it's still like, still like fast enough for, uh, you know, the, the most of like use cases. Eduardo: And if you're unhappy with how. Like that, that's going, you can just write your own, like, you know, Java wrapper that does like patches, a few operations, if you, if you, if you like really needed it, but I don't think we ever needed that on a project. So, [00:12:26] Ad Andrew: this week we'd like to thank our sponsor, but we don't have one. So if you'd like to sponsor the DevToolsFM podcast, head over to DevToolsFM slash sponsor to apply. Andrew: If you want to find another way to support the podcast, head over to shop. devtools. fm. There you'll be able to find all of our cool merch and really rep your nerd swag wherever you go. Andrew: But if you want a little less public way to support the show. Become a member on one of the various platforms where we offer it. There you'll get ad free episodes and you'll get the episodes just a little bit earlier. With that, let's get back to the episode. [00:12:57] Exploring NativeScript Runtimes Andrew: So you mentioned run times a little bit [00:13:00] there. I saw a tweet from Jamie about how like JavaScript core you can like called directly to objective C methods. So, like, what are explorations are you doing with new run times? And, like, it seems to me, it seems like it would be very hard to change that at all. Nathan: Well, I should mention JavaScript core specifically. The NativeScript runtime was originally written on JavaScript core for iOS and it was extremely, you know, mature runtime. Um, the, uh, Telerik and Progress both did a great job with that runtime. Sometime around 2019, 2020, it was adapted to V8 and V8 had a much more, uh, easier to use API, I think, in general. Nathan: And, um, it was also evolving, you know, in, in a public way. And so it, Around that time, it was shifted to V8 and all the focus was put on to V8 for really two reasons. I think one was maintenance, but also number two, uh, it aligned the engines between [00:14:00] iOS and Android because Android had always been on V8 and then iOS was on JavaScript core. Nathan: And so there were very subtle differences between those two. So everyone wanted those two engines to be identical. So they are identical today. Um, Other engines, um, is like right now, NativeScript runs on Hermes. Um, there hasn't been a whole lot of information published about this as of yet, mainly because there has been a pull request sort of hanging in flight to bring node API to Hermes. Nathan: And, um, you know, when, if that lands, I just heard an RC was published with it and others were invited to sort of experiment with it. Um, we've been working with that for maybe three or four months now. And, um, we do have some, some Naverscript examples working like an expo, for example. Um, but a public release on that probably wouldn't come until sometime 2025 more because number one, it depends on upstream Hermes changes to support node API, but also, [00:15:00] um, we want to bring the engine to Android before there's a full public release there. Nathan: But, you know, you mentioned. Go Nathan: ahead. Eduardo: So, uh, like just to expand a bit, like we are also, uh, planning on like creating, at least improving our runtimes with like a common API so that like, um, you could hook, you know, leadstrip into whatever, uh, runtime you have. Right. So right now, like they're very, like, uh, focused on like specific tasks, but ideally we want to like completely decouple it from V8, you know, our, like how, our whole like object system and everything we want to decouple from V8. Eduardo: And then you can just use that in, you know. Hermes or quick or whatever, like shouldn't matter. Nathan: Yeah, I think I should mention quick JS as well. There's some other contributors around native script. They got it running under quick JS, which is another engine too. So there's definitely quite a few like adaptations out there, which brings up a good question. Like, what is native script when you start talking about it in terms of these different engines? Nathan: I think it's 1 of more interesting. Kind of conversations around it [00:16:00] because I think originally when it came to market, it really was sort of, um, centralized around a product focus, you know, and I would say, ever since it's, um, been sort of shifted to the open just foundation. NativeScript is more an approach with JavaScript to bring platform development to JavaScript. Nathan: And so it really is intentional today, um, that native script aims to be as adaptable to any engine and really any environment in which you want to use that approach. Um, And I mean, once a truly drop in adaptable engine layer is available, then I think that will ring true, I think, to that statement. Justin: This is, this is really fascinating to me. Uh, so, I mean, going back to sort of the early conversation about, you know, there being some, maybe. Contention around like native scripts approach. I found like, I was super excited about it because building apps that like cross layers is like, Oh, I want to do all my [00:17:00] work in JavaScript, but I have to, you know, integrate with the system at some level. Justin: It means that there's like defining foreign function interfaces or whatever, like a bridge for your, you know, app, your JavaScript world to talk to the like hardware world is always just such a pain. And it takes like specific expertise across every platform. And Even today, anytime that I do FFI, it's like always, it's, it's still a pain. Justin: Um, so it was like, I'm doing some Dino work and I'm like trying to work with like native web view APIs. And it's like, it just, you know, I mean, Dino is like Dino and like the node APIs we have today are worlds better than it used to be, but it's always still a pain and it's like this idea, this promise is like, Oh, like it's all just JavaScript and you can use any of the system native APIs is, is. Justin: Magic just because the idea of it's like all generated at Justin: build time. Nathan: And be, be careful of saying magic. People don't Nathan: like that word. Well, I Nathan: mean, it is magic Nathan: though. [00:18:00] Right. Nathan: our, our, our, our, our kind doesn't like that word, right. Engineers don't like that word. Um, but yeah, I mean, that is the feeling, um, you get certainly, you know, when you use it, uh, it, it never wears off like that, that feeling of magic is with you every day when you're working with it. Nathan: So it's true. Um, I shouldn't mention, you mentioned Dino. We have native script working on Dino as well. And actually there may be something out on that in the next couple of weeks. Um, For the desktop, but the. I think the, the general thinking, like there's, um, there's sort of this mentality, I think, in, in development, if you've ever worked day in, day out on somebody who's over your shoulder, wanting to say, go this way, go that way, go this way, go that way. Nathan: And it's, and it's always reaching and reaching and reaching and reaching, you know, you always, I think it's always a difficult position to be in as a developer, to be able to say, no, we can't do that because our stuff is Um, and therefore the question comes up, well, do we need [00:19:00] to change our stack to do this? Nathan: You know, and that's always a difficult decision for any team. Um, and if you've ever been part of a team that's had to migrate from one tech stack to another, it's, it's a, you know, usually a pretty large undertaking. It can be very painful. Um, I think the general. Idea with native script is that it leaves nothing off the table. Nathan: Um, you know, the, the very essence and spirit of it is that you can do as much Swift UI with native script as you want. You can do as much jetpack compose with native script as you want. You can do as much flutter with native script as you want. Um, and you can even move in between those paradigms as much as you want. Nathan: Per case. Um, and that is kind of the essence and point of it. We use React Native plugins in NativeScript today, you know, through a community effort called OpenNative. And that's a really brilliant effort led by Amar Ahmed, who's, who's from the React Native community and Jamie Birch as well. And, um, It's a sort of, that at least shows what [00:20:00] NativeScript brings to the table, I think in [00:20:02] NativeScript's Flexibility and Plugin Ecosystem Eduardo: One thing I also like, I always like to mention is, uh, Um, like if you can do something native, you can do it inside native script, because essentially NativeScript is just exposing native to you, right? So if you can run React Native in native, you can run React Native in NativeScript so it can run, if like React Native is able to call, you know, functions like native functions that receive a JSON, you know, sometimes you can just call them, uh, from NativeScript as well. Eduardo: So that's like the basis behind OpenNative itself, which is just like a layer that does this translation for you. Right. Andrew: Uh, do you have to define that layer? Is it like all code gen, like how much work actually goes into defining all of those APIs? Nathan: none, it's all Codegen. No, the, the open native layer is kind of neat because it does, um, handle sort of the Gradle and Objective C layer. You know, when you bring a react native plugin in, I should say that right now it's pretty much focused on SDK [00:21:00] layer plugins, things like, um, um, React natives, community, uh, net info. Nathan: For example, or react native off zero, um, we've used that in native script apps before. Um, those are more SDK level. They're not so view focused, but Amar has, uh, allowed open NATO to be working with react native web view, which is actually view layer. So the view manager does work, uh, an open native in native script. Nathan: Um, generally for some pretty complex view, uh, react native plugins, those typically you would probably want to adapt, um, you know, to some, to some degree. I mean, in, in yes, it does mean you could use a react native plugin in view, you know, you could use a react native plugin in angular. Um, you can do that with open native. Nathan: Yeah. Justin: And as you know, as I'm thinking about, about this is like, when I discovered native script originally, it was like the, the point was just like, or the point that I interpreted at the time was like making building apps simpler. [00:22:00] Uh, just using the languages, you know, like just using JavaScript. Um, And there are like some were some incredibly strong benefits for it. Justin: So one is that you don't have to recompile after like every change that you do, even if we're accessing native things that it, the, the improvement of iteration speed is huge. And y'all even today have this like preview feature that is absolutely crazy. Um, I mean, I think that like other parts in the ecosystem, like expose is really good and like providing previews to, so the whole. Justin: Sort of ecosystem is like really leveled up, but I still think like native scripts preview is, is pretty wild because you're, you know, really touching on like native APIs and stuff. and that's a impressive, Nathan: I think the, the Namescript community would love to work with Expo. I mean, you know, more in bringing that stuff to Expo, I think it's important to delineate the, the line, which is what Namescript enables is not something that is [00:23:00] barred or lined from Redact Native. You know, I, I think maybe traditionally in the past that was thought to be the case, but, um, it's really not true. Nathan: Um, you know, Namescript and what you can do in preview can also be done in Expo, um, through. Through what we already have working. And of course, when it's, when node API is enabled in Hermes upstream, you can probably get that right away, certainly for iOS. And it sort of bears the question, you know, what are the use cases in which you would use that? Nathan: I mean, you know, it's hard to, it's hard to say right now in terms of different projects and challenges that are happening, but you can maybe use it as a quick, um, sort of enabler just to try something out. And then maybe you do want to then write that in a Swift layer and objective C layer, but it's sort of a quick enable access. Nathan: You can maybe try something out, see if that direction is going to work. And if it does, that's, that's sort of the thing I think we like. Working with it with professional development is that we can tool it when we need to. So if there's [00:24:00] a case where we want to drop down a layer, we can, um, you know, and we're not, uh, it's not, uh. Nathan: A big deal to do. So, um, you know, if, if, for any reason we were building out some view that we decided we wanted to optimize in some particular way and we want to decide to cut this portion out, maybe do that down in an objective C layer, maybe we want to drop that in the swift or even Kotlin, um, we could do that and it could still plug into the whole system. Nathan: We don't have to shift our whole stack to do that. Nathan: We have, um, there is an app that I think, uh, Ed is even using for his lighting today, um, that is a native script app that, where we did a lot of this, uh, with, um, and we can maybe talk about it a little bit more in direct relation. Cause I think sometimes these concepts are hard to talk about, uh, on the surface, unless you're really talking about it in like real. Nathan: Um, so we can, we can, uh, shift into that in a minute, but I don't want to get too, uh, too direct in there just yet. Andrew: Um, so you guys have talked about plugins, [00:25:00] uh, but like, what, what is it exactly plugging into, like, is it adding like specific, like platform specific files and like bindings, or is it plugging into like the bundler? So, yeah. Nathan: Great, great question. I'll let Ed comment on this too. But, um, what I'd say about plugins is plugins are just conveniences. Um, you know, more than anything, I think it also like consistent APIs. You know, I think those are the two forms of which you approach plugins. Number one, um, can I get this thing working faster? Nathan: Number two, can I get this working in a consistent way between iOS and Android? Because oftentimes that's the point all along, right? Um, you, you usually choose some type of hybrid tech because you're going to do multiple platforms from one. So those are the most common, um, Questions that are easily answered with plugins. Nathan: Um, the fact is, is that you can do the plugins, of course, internally to projects. And we've done that a lot, you know, over the years where, you know, if a plugin doesn't exist, well, because of what NativeScript enables, you can write a plugin easily inside on the project and [00:26:00] create your own consistent, um, API if you want. Nathan: Um, you know, that only makes sense in certain cases. I mean, there are a lot of plugins out there for some pretty concrete cases, um, that you would need. But, um, You know, I think community size and, uh, you know, when you compare it to the plugin ecosystem around react native, it's definitely, you know, I think it's hard to compare, um, because that ecosystem is Nathan: very large. Eduardo: So like what NativeScript enables, right, is, uh, like core API access, right? So like native, but when you're like choosing the technology you want to develop your app, uh, if you are just writing, uh, essentially like objective scene JavaScript and Java and JavaScript, uh, why are you just like not developing Java in your Objective C, right? Eduardo: Uh, So the reason that plugins mostly exist, uh, is that more often than not, you probably just want, you know, to install a plugin and, you know, uh, just use like a common API, right? So [00:27:00] plugins are usually that. So if you look at like the plugin code specifically, I mean, some of them actually do. Add some, you know, uh, Java code or Objective C code or whatever. Eduardo: Uh, but most, mostly you see like, you know, it's like an, uh, app gradle with no specific dependency that gets pulled in. Then we pull in when you install that. And then it's just like, you know, a file for Android, a file for iOS and like a common API that just interrupts with whatever APIs that you have. So it's more, uh, it's more like a very like convenience, I think. Nathan: Yeah. But I think to answer that maybe concretely as what is a plugin is often a pod file. Maybe on iOS, a plugin may bring in a pod file for you that brings in, like, if we talk about Firebase SDK, there's a iOS SDK. So the Firebase plugin for NativeScript would bring in that pod for you and attach it into your project. Nathan: The include gradle that would come along with that would also attach the Android SDK for Firebase. And that's often [00:28:00] what plugins are doing. They're, they're bringing those platform dependencies in, and then they're providing basically a surface of a common API usually. And that's that's usually all they are. Justin: nice. [00:28:09] Framework Integration with NativeScript Justin: I'd like to talk a little bit about framework integration. So, NativeScript has a lot of examples and tutorials on using a web framework that you might be familiar with. So like Vue or React or Svelte or Angular. Um, and we've already kind of talked about like The model is more conceptually similar to react native than it is to Cordova. Justin: It's like, this isn't a web view. It's a native view that you're rendering these UIs to. Uh, so how do you bridge the gap between we have this web framework and we want it to render in these native views? Like, what does that translation look like? Do you have to write sort of custom code to like, I don't know, hook into each framework. Justin: I know react has its own reconciler. So it's kind of easy to plug in, but I'm not sure how the other frameworks work in that regard. Nathan: This is an interesting conversation, and I'm gonna [00:29:00] let you get into the render part. Um, it's an interesting conversation more because of the historical nature around NativeScript core. NativeScript core really is sort of like a condensed layer and API that basically uses everything the runtimes provide to create, um, some sort of consistent, you know, API, which is what NativeScript does. Nathan: The web is right. Um, and so that's where often a lot of confusion comes up. You know, if the web has already got this consolidated API, what is this thing? NativeScript core. Um, let's talk about that a Nathan: minute, Eduardo: Yeah. I mean, core core is kind of like, uh, the way that I usually like to think about this is imagine like you're developing an app where you're not allowed to use, you know, div or anything like that. What you're allowed to use is web components, you know, so there's a web component that has like a specific layout, a web component, a web view or a button. Eduardo: So that's how essentially like I'll need script kind of like works, right? So everything, every, every component that we provide in its core actually is just like, [00:30:00] kind of like a web component that you're using and then, uh, Uh, what we have is, uh, we usually have to write our own renderer, right? Uh, or extend the existing renderer. Eduardo: So for example, I usually maintain, uh, the Angular integration or the Angular renderer. Uh, and Angular is like pretty easy to extend. There's just like a class that you just, uh, you know. Implement. And then you just, you know, essentially we add everything through JavaScript. So when you, you know, add like a child, I just called an Xscript API as a child to, to a component. Eduardo: And then depending on like, what's the, you know, the name of the component, I Put some kind of, uh, you know, I know like if you're, if you ask for a button, I know that I have to like get an history button to put here. Right. Uh, and that's how pretty much our, our other frameworks are, are done. Right. And some people think like, well, but why not kind of like just emulate the DOM would be, uh, Uh, you'd think it would be easier to do [00:31:00] that. Eduardo: Uh, but the problem is, and I think like that's a pretty big problem that I see is that people don't realize that when you're dealing with a native app, right? So when you're dealing with a web app, you have, uh, you know, Your browser, and then you're writing your code inside, uh, you know, the tab that you're working in. Eduardo: And then the user opens another tab and it's another like instance, right? When you develop a native app, you're developing the browser. So if the user wants to create, like, you know, if you want to open a model or if you like, depending like applications now, uh, are now able to also be multi, multi window, you know, all these, all this has to be like, uh, You have to handle all of these and it's not like just, Oh, well, just make a DOM. Eduardo: Okay. How do you represent like two detached DOM trees that, you know, uh, you know, when you say like document dot add something or create something, how, how do I know which DOM tree you're, you're adding? So it's kind of like, uh, you and, Especially like [00:32:00] model navigation where you open a model and inside this model you have your own navigation and once that that model goes away you want to go back to like the previous navigation that you had in, right? Eduardo: And this is done like on iOS with like view controllers and everything like that and that's something that DOM just cannot represent. DOM is something that you, like, you can open a model and then you can replace the contents of a model that seems like a navigation, but it's not really a proper, like, native navigation. Eduardo: And if you want native behavior, you're going to have to express things in ways that, like, the DOM was never, uh, thought to be, uh, you know, possible to do. So it's, it's more like, it's, it's a tricky thing. It's always like a tricky situation. And then sometimes you also like have, you know, virtualized lists, uh, which is also like a, a pretty big deal on, on, especially like mobile, when you have like a, uh, you know, we have like an app with like a virtualized list. Eduardo: That's always, uh, you know, a performance nightmare on whatever framework that you're working on. Uh, And you have to express that. And, you know, if you express that [00:33:00] kind of like in a DOM way, it's bound to be, you know, probably inefficient and not exactly what you're looking for. So it's, it's makes more sense to have like, you know, you create your own, uh, I mean, you create your own renderer and then you use this kind of like web component in, in a way, uh, to like get the result that you want. Nathan: So that, that conversation, I think also has to be discussed in a way that you talk about divs and a tags in the markup itself. Like I think a common confusion and frustration is, well, why can't I just use a div or an a tag here? The reality is, is you really could. There's a register element API, and you could actually register the div in the A and just have that match. Nathan: And we could even do that for people through core. Um, so why wouldn't we do that? Um, you know, I think in general, To fit all of the, the web cases that are out there. If you take about, think about taking your website that you have today and using native script to run that on [00:34:00] iOS and Android, but run it natively. Nathan: So now you're running it, rendering it natively, but you're, you're taking your markup that you've already written and run it exactly as is what exactly is your expectation there? Um, We could render it pretty close. Um, but there are cases like float left, float right on some of those divs is some of the resetting that you may get on div flow layout, um, that we can make a general assumption about how that should render, um, in native land and could probably get pretty close. Nathan: Jamie has some examples out there where he, um, did exactly that of, um, using NativeScript to render. I think it was Reddit. Uh, feed and he rendered the exact markup actually using NativeScript. Uh, and it actually is pretty close. Um, could you, yeah, you could do that. Um, and we could probably release something that would just allow you to do that. Nathan: But then does it bring up this whole complaint of, well, you know, that's not exactly, What my, you know, web market was doing. And now we have this whole other conversation, um, to have, um, could [00:35:00] it get you most of the way there? Probably. Um, it could definitely be a quick, like POC way where you could take some website you've written and just run it natively and then start sort of tooling it from there and make decisions on, on what you want to do there. Nathan: So it's a conversation that's been evolving, I think, around the script since the beginning. It's probably closer to being some DOM layer out there that you could use in lieu of, um, another conversation we'll talk about here, which is Namescript Foundation, which is sort of a new modern evolution of core itself. Nathan: But, um, we'll touch Nathan: on that in just a minute. Andrew: There'd probably also be like perf concerns with that, right? Because we were, we were talking with like, uh, the Tomagui creator, and it seemed like a lot of the work he did to like, try to make it more performant is like combining like elements basically so that it, uh, it rendered the view faster. Nathan: Yeah. I mean, you might be the most amazing web markup. Engineer out there and believe your markup is super tool, but we know there's a lot of [00:36:00] nested divs out there on the web. And, you know, if each nested div equates to a UI view and UI kit, for example, on iOS, it's a lot of unnecessary nesting. You can achieve the same layout with one, you know, in native land. Nathan: And so you can get away with a lot less in, in platform tooling, just by nature of what it provides. Andrew: Yeah, another interesting point we had in the conversation with the Tamagui guy, uh, was that like React Native, you're basically building as, uh, Eduardo said, a browser. And with that comes a lot of stuff. [00:36:35] CSS in NativeScript: Real or Translated? Andrew: So like you, you guys support CSS, uh, which I'm pretty sure it's probably not like real CSS. It's like a, like a translated CSS. Andrew: So, uh, Am I right there? And are there other things that you've brought from the web web platform to native script to make it feel like you're more in a browser? Eduardo: But my question is, what is real? In the end, what is real? Nathan: [00:37:00] you know, the, the the CSS and even core discussion, um, back in 2014, it actually Navescript was released, I think March, 2014, actually. And I'm, um, so yeah, it has been quite some time. I, it, core originally had factions that were written in, um, native land. And then it was adapted to JavaScript because the runtimes actually provide that ability to do that. Nathan: Um, and it also sort of opened the door for core to be easier to contribute to because most people could contribute to JavaScript easier than they can contribute to Objective C or Java layer. And now today we're talking about maybe taking some aspects of that back, um, down a layer. Um, the reason being that is, is core itself. Nathan: When you talk about providing a layer that you can work with something like CSS, um, in the aspects of the web that you want, um, you want that to be as optimized as possible so your userland code can get a little wild and willy and that's fine, but you really want to be building on top of the tightest, um, core foundation possible, um, because that's what the web platform [00:38:00] provides, right? Nathan: Um, CSS is definitely one of those topics where, um, it's really heavily optimized. I mean, core is an optimized layer for sure. Um, it's not slow by any means. Um, but when we're talking about, Optimization. We talk in very minutia details. So I think it's important to pick up that, um, oftentimes when we're talking about optimizing, we're not talking about optimizing due to necessity. Nathan: We're talking about optimizing because we can become freaks about performance. Um, and all of us can be. And so, you know, that's usually what we're talking about. Um. CSS is one of those. Uh, it's it's definitely implemented in JavaScript and core right now. So NativeScript core is what provides the ability to do CSS and NativeScript. Nathan: Um, that same implementation could be provided by a foundation layer that's done in, say, C plus plus, um, just the same way. Um, and it's likely that to happen in the future. Eduardo: Yeah. Additionally for that, like, Eduardo: yeah, like the, like the bundler itself, like we don't use like a CSS bundler that just like, you [00:39:00] know, puts some string into your app. We actually like to convert your CSS into a JSON or like a, you know, uh, an object. And then that just becomes easier to process, uh, you know, So, uh, it's, I mean, we are like still, you know, doing like CSS parsing and we are like setting properties that you set from CSS, but it's just that, uh, I mean, it's a subset of CSS, right? Eduardo: It's not full CSS, uh, but it's like good enough that it allows you to pretty much like style as you would on the web for the most part. And yeah, for sure. It's just like, yeah, it's, yeah, it's not like a real, but it's also like, you know, in the end the browser is doing the same thing, like you're passing, passing like a CSS and it's just going to like parse it and then use it in a way that we can understand. Nathan: let's say the other thing is sort of interesting about CSS and core is that it's, it's pretty approachable, like if you wanted to drop a new property in core and make it CSS adaptable, it's actually pretty like we could do it in like probably [00:40:00] 5 minutes on this call right now. It's, it's, it's very approachable, um, There's a style property class in there. Nathan: And you can basically flag anything to be CSS stylable. Um, and it becomes part of the style class and you give it the exact name that you want it to be, uh, in CSS. And so it's, it's, it's pretty empowering and sort of fun in that way. Um, But it's, It's also wild in terms of what you could do, because you could introduce a whole bunch of new CSS properties that, you know, are totally foreign to the web. Nathan: So I think part of the philosophy around NaveScript is not to diverge too far off of it. I think over time, there were times where it maybe did, um, you know, in the early, late, Teens there, you know, and I think part of what the working group now is trying to do and bring a lot of winter CG, um, and winter CG is of course, this great group doing, doing awesome work in the space to try to, uh, create a common baseline that any innovators around JavaScript runtimes can coalesce around, at least for non browser environments, which certainly NativeScript is. Nathan: And, um, you know, we're [00:41:00] currently working towards implementing their full winter CG, uh, spec. And that just brings some common expectations, I think, from engine to Nathan: engine. Justin: I was just wondering if I had opinions on styles, like if winter CG had any opinion on like CSS or like styles and engines, Justin: I haven't seen that yet. Justin: I didn't, I thought it was just like, runtime stuff. Eduardo: Yeah. But ideally, like we want to create like a, you know, we do want to create kind of like a div, uh, in, uh, They trip and this is like essentially going into the future. We want to create, you know, like our API, which is kind of like. Uh, you know, or, or like, at least like C plus plus, you know, Dom like API that we want. Eduardo: And it's more like, we still, you still were going to be able to, to, to use your views and create your views in JavaScript, but it's more like, you know, uh, so that you're not like as punished by. And like, so bought optimal with your layout, right? Because like a lot of times, like if you're just using like margins and paddings, most of the time you don't need like a new wife. Eduardo: You just need like a, a, [00:42:00] you know, a different kind of like rendering, you know, or a different kind of like layout calculation. So we could save views there. Uh, we are like looking into a, I mean, we have like a few project ready, uh. Like a plugin that's using taffy, for example, uh, you know, for, for that. And then we're just trying to expand that. Eduardo: And then we've that, and, uh, you know, improving our, uh, CSS engine under the hood that just enables you to know, it's just like a quick win to improve your performance in your app. Justin: Yeah. I think there's, you know, this interesting thing here. [00:42:34] Balancing Web and Native Performance Justin: We're sort of like denser on this conversation is like all abstractions are leaky and there's like things you can do to make the environment feel more familiar. It's like, Oh, you've done web stuff here. You can do kind of some of the web stuff that you've done before, but like targeted at native, there's always this question of like the balance of like what you do, because at the day, it's translated into something different and the more ignorant of. Justin: That you are, the [00:43:00] harder it is for you to build a really performant app, you know, and the more work you as maintainers have to do to build sort of like these, you know, well architected abstractions and really, you know, think about like what you provide and what you don't provide and how you document corner cases and all this stuff So this is an interesting tension. Justin: I saw this back several years ago, using react native and trying to bring react native components or like, uh, across native and web design system. Like the Tamagotchi guy I was talking about, but it's like, you know, react native, uh, web was the recommendation. It's like, no, we're not going to make react native like web. Justin: We're actually going to make web more like react native. And it's like, you know, there were all these implications and in my. Experience in the company that I worked for. We ended up just like completely divorcing them. You know, it's like, you know what, we're not going to share code at all. We'll just like, you know, share the designs and we'll have a different design system. Justin: So this is an interesting and Justin: challenging [00:44:00] tension. Nathan: Naive script kind of takes that same approach. Like if you're going to do web with NaiveScript, which is one of the most common questions, you know, we've got a web app here, we want to bring iOS and Android on board, um, you know, our recommendation today, and it's how we do it is, is we put in a workspace and then we share all the bindings and the logic you can share component data. Nathan: So what you're left with at the end of the day is really just a platform decoration for. Whichever, um, you are. So ultimately you have Dom markup, you know, for your web stuff. We personally prefer that because you can optimize for each case. Um, and you're not sort of stuck in one land or the other. Um, so it allows you to sort of use like the most optimal best way that you want on a particular one. Nathan: And, and instead of being sort of in this just generalized land where You know, this should generally work there and this should generally work there. Um, I want it to work precisely, you know, as the web's intended here. And I want it to work precisely as it's intended on iOS and Android. And I think the, [00:45:00] um, that also brings up a topic that I've heard a lot of confusion on, which is, um, the runtime and what, how that works and, uh, how that compares to transpilation, because I think the term transpilation comes up often, um, When you're talking about these technologies, and it's a very different concept, um, and what you end up with at the end of the day. Nathan: And the constraints are very different. Um, transpilation is really the fact of taking one form and fashion of code and transpiling it into another. So you're sort of transforming into another. That is not at all. What NativeScript does, um, NativeScript doesn't transpile anything. It actually runs it directly as is. Nathan: Um, and that's a really key philosophical point and approach because you, it's really trying to give you how you would work with the platform. If you were doing with it in Swift, you're just doing it and TypeScript and it, and it runs in pretty much the same way those calls are being made in the same queue, they're being made against, you know, the same thing. Nathan: And you're, you're ending up with exactly what you're coding. It's not transformed into something else. [00:45:57] Real-World Examples and Ecosystem Andrew: so, uh, you [00:46:00] mentioned that it might be, uh, interesting to ground this in like a real world example, the, the lights example, but, uh, you want, could we dig into that and maybe some of like the tooling and plugins and the ecosystem that you guys really like using? Nathan: Yeah, where should we start there? Um Maybe, yeah, maybe we'll just start with the ecosystem. I think in general, you know, I think the, the flavor renders definitely are all contributed by the community. I think Ed mentioned the, the Angular render, which is really excellent today. Um, the view render is done by Igor Rangelovic who's on, um, the working group as well. Nathan: Um, the react, uh, flavors done by Jamie Birch. Um, the svelte flavor is done by, uh, Hanson, um, or Hapnelson. I think as we, uh, know him, and then also the solid layer was done by, um, Dominative, which is, um, uh, oh gosh, Ed, remind me. My mind's going blank. Not classic song. I want to call her by her name. Eduardo: Uh, yeah, I was a mute. Sorry. Uh, youkino song. I think it is, isn't it? Nathan: Yukinosong, thank you. She's a [00:47:00] brilliant person. She also created this library called Dominative. Dominative has a nice aim to actually bring DOM. So we were talking about DOM emulation. It's really a DOM approach with NativeScript that could enable flavors more easily, just as it is without their own custom renderer. Nathan: There's been some discussions around DOM. That, um, you know, often the, um, the NativeScript community plugins, we use a lot of those, um, in, in our, uh, projects, certainly, uh, Martin, um, Guyon, if I pronounce it right, Martin Guyon is the one who, uh, often is, uh, authoring a lot of those plugins. Um, he does a great job there. Nathan: Um, OC fortune also does a great job in the community with, uh, things like canvas, we use the canvas plugin that he created to do some pretty sophisticated 3d, um, animated and, um, audio visual work in a, in an app, um, just [00:48:00] last year. And those probably. Top the list, at least for me. I don't know, Ed, if you have any particular call outs. Nathan: I Eduardo: Uh, I think you like hit most of them actually. Nathan: mean, Valor has a few too. There's a web socket one. And if you need web sockets, the Valor web socket plugin is definitely excellent. Um, we just, uh, actually adapted that to vision pro as well. So there's a vision pro slice in there too. Now [00:48:23] Expanding Platform Support Justin: So something I'm curious about is we've, we've talked about sort of like iOS and Android. Android and, you know, even Vision Pro support, um, and hinted at, you know, potential desktop integration or running on other JavaScript engines like Quick JS or Dino. Um, and Desktop integration is an interesting question. Justin: This is like, uh, I could see that being very natural for like the OSX ecosystem because iOS and OSX aren't too terribly divorced. I mean, different, but you know, and the same ballpark, but like, you know, supporting [00:49:00] windows is a whole different beast, you know, even because there's like a lot of different base generation. Justin: So is desktop something that you're thinking about? Uh, going into, or they're like other platforms or how are you kind of thinking about that? Nathan: I think it's good to state that platform support is driven in Naviscript by real world need. So if there's a real world project that demands it and wants it, then often it's done. Um, it's not a matter of can it be done? Of course it can be done. It's just a matter of prioritizing. Um, you know, Windows has been done in NativeScript back in 2018, I think was the first time that Windows was done with NativeScript. Nathan: Um, there's a POC, I think Bundio, uh, who was on the, um, core teams in the past had done an iteration on that. OC Fortune has also done a Windows iteration with NativeScript. Um, MacOS and Catalyst is enabled. Um, you know, you could do some of that today. The Dino and running desktop there, uh, as I mentioned, hopefully in the [00:50:00] next couple of weeks, there'll be an example out there where people can sort of explore there. Nathan: Um, cause there has been some work done around that desktop support. As far as kind of getting behind and making it as like fully flushed out in first class is iOS and Android probably just comes down to, you having that professional need to do it. You know, I think that's what drives, you know, everything in NativeScript vision pro came about because, um, there's actually a client who wanted that to actually work through that. Nathan: And so that became available by that. And so, you know, for anyone out there who wants platform support, that's usually how it happens. Um, Desktop, as far as like bringing that fully out, if we were to take it as the approach of core and adapting, um, all of core to desktop right now, core is split out in iOS Android files. Nathan: You know, each of those contain the implementations of those in native script. The same thing would be the case for Mac. You could do a lot of [00:51:00] catalyst stuff currently, as is without much change. Difference probably more so would be in the boot up process. Um, in some of the, um, kind of initial handling of, of the app, um, but a lot of the APIs, um, to navigate, um, catalysts would probably work sort of as is, um, TVOS is more likely the next one that we would bring to the fold. Nathan: Um, actually have a TVOS adaptation up on the iOS runtime right now, um, which is probably more for like a 9. 0, um, major release in, I don't know if that would be Nathan: this year, but more likely next year. Eduardo: Yeah, one thing like to consider is like most of the, the things that you're going to use and to be like, for example, if you're using QT or, you know, a, or whatever, uh, they have like a, some kind of C API and we, unlike the iOS runtime, we already have all like the infrastructure to call any C API you want to call. So [00:52:00] it's kind of like, uh, you know, it's not like a huge amount of work to just bring that into, you know, Windows or Linux or whatever we want to bring. The problem is like, as Nathan said, that, uh, then you just, you know, you don't, you're not going to just like, okay, so here's like the, you know, the, uh, Windows runtime or so use this to use Qt and I would just have to write all your Qt code in, in, uh, you know, in JavaScript. Eduardo: So it's kind of like, it's, it's, Eduardo: yeah. Nathan: Yeah. We'd want to bring like core to that. I mean, the reality is, is you could do windows, you know, with native script, we were saying today, but no one would really want to do that, you know, for an app build, we'd kind of want to bring core to it. Or we wouldn't want to release that and say this, you know, use this for professional development. Nathan: We'd want to bring core probably to it. And that way you can use everything that's Nathan: documented in the native script docs to do that. Justin: So specifically here, it's like, not about the generated bindings. It's like, that's a very practical problem, but it's like [00:53:00] the abstractions that exist on top of that and figuring out how to do those in like a way that would support cross platform that is more of the like longer tell effort that would need to be supported to like really bring this, you know, to the Justin: community. Nathan: And it kind of goes back to one of those original questions, which is like, well, if I could just use div and a tags and there's my markup, just make that work across all platforms. And, and, you know, the answer is, yeah, we We could do that. Um, you know, I think it would just be documented in the edge cases around div nesting and, and things like that. Nathan: So, you know, I think the more DOM API has brought into core, which is some of that discussion that we're sort of hinting at, which is there's Namescript core, and then there's this discussion of Namescript foundation, which Namescript foundation is a new package that the worker working group is putting together to kind of boil down most likely CSS and C plus plus some aspects of core. Nathan: They come in on a C [00:54:00] and it may create a, um, undercurrent underneath core. That'll enable some things like that, um, potentially more directly and easier. Maybe. Andrew: Uh, so what do you guys have planned next? Like, is foundation the main focus or are there other big initiatives going on? Nathan: Foundation is, um, definitely where a lot of discussions are taking place. Um, currently, I, I think outside of other platform support, like if TVOS, um, you know, comes around for 9.0, I think, um, there'll definitely be some, some efforts there. But foundation will probably take, um, take most of the focus, um, predominantly I think. Nathan: Um, I should mention like bundling support. You know, there's been some questions around VEET. Um, currently webpack is used predominantly. Um, VEET is possible as well. You know, I was just talking with Igor on the working group the other day, and we may actually [00:55:00] do something around VEET for VEETconf in October. Nathan: Um, you know, the main thing with VEET. is around HMR. I think enabling HMR through there, I think is import maps with to do, um, some of the HMR stuff and import maps. I don't think are currently supported on the runtimes. So if we wanted to bring HMR through VEET, we'd probably want to make some adaptations in the runtime. Nathan: But other than that, the bundling would just work. Um, we didn't see any Nathan: trouble there. Eduardo: Yeah, we're also like improving a few things on [00:55:27] Advanced Features and Shared Memory Eduardo: the runtimes that are Pretty interesting, for example. So now we have, at least on the iOS runtime, uh, we're still like bringing a few things over to the Android runtime, but we have, for example, shared array buffers. So you can share like blocks of memory between, you know, your JavaScript and a worker that you create, just another thread. Eduardo: This is already used, uh, in an app that we develop, which is the one that I'm using right now to, to like handle my lights. Right. Because. Usually when you're dealing with, you know, this, this app actually use the C API that just receives, you [00:56:00] know, like a void star. So essentially like a block of memory and you just say the length and then it just like transmits to the network. Eduardo: And, uh, what NativeScript does and like, that's like a part of the beauty of it is that if it sees like, well, this receives, you know, like a pointer and you're passing an array buffer, we don't copy anything. We just like, you know, we grab the buffer completely and then we send that in. You know, if you want to copy, then you can, you have, you have IPOs, APIs that you can call to copy that. Eduardo: But, uh, ideally we just, uh, then all of that block in. So there is like zero, there's a zero copy, you know, kind of like policy to, to try to not, uh, do, uh, any kind of like heavy operation that, that you are not expecting to, to happen. So this is like for, uh, for Android, it also happens for Eduardo: like, Nathan: Ed, Ed needs to Nathan: write a Nathan: post. And Ed really should write a post on this topic. I mean, shared array buffers and the discussion around that and also talking about shared memory, which I think has been rightfully so a common, [00:57:00] um, complaint or mark, uh, that is used often against NativeScript because the assumption is that everything is, is, uh, perhaps copied in wrappers. Nathan: But the reality is, is you don't have to. Um, and so the shared array buffers actually is, is a way to avoid that. And yeah, Ed, Nathan: you should write something on that. Eduardo: Natescript, like you can Eduardo: also, I mean, JavaScript is single threaded, right? That's like, uh, given, everyone knows that. But the, the, the thing to consider is like, uh, you can only have one thread access in JavaScript at one specific time, but not the same thread. So you can have like other threads that enter, you know, your JavaScript blend to do things. Eduardo: Then exit, right? Of course, like that will block the main thread if the main thread actually needs to do work, but you can use that for like a small things that you're just, you know, call like a function and it is going to return like on a different thread. You can, you can do that. Uh, and, uh, or you can use of course like workers and workers just means like there's a new JavaScript isolate. Eduardo: So there's a new, like, you know, JavaScript instance that's [00:58:00] running. That's not going to block your main thread, but you can still like pass, you know, like if you're using like a UI view or I mean, UI view is like a bad example, because if you try to change any UI view on like a background thread, It's going to crash. Eduardo: But there are like other objects that you can pass in, uh, that are not depending on, on, on any thread. And you can just like send to a worker and then send it back. I mean, or you can just have the same reference on like two different threads, you know, uh, working with them. And then you can just, uh, you know, interrupt like seamlessly with, with threads or whatever you want to, to Nathan: let's look at that after you were talking about that does that. So Nathan: I don't know if you can show that, um, or what's lighting you Nathan: here. this Nathan: this is, Nathan: um. [00:58:43] Showcasing the Lighting Console App Nathan: this Nathan: is an app that Ed, Ed and I did work on together and it is, it has been, um, um, uh, an exciting development for the both of us just because it, it, it does delve into sort of all these topics that we've sort of been talking about, but, um, it, it handles a lot of data, um, and, [00:59:00] and it does so in a very efficient and, and memory efficient manner using NativeScript. Nathan: So the, the. The app itself is a lighting console meant to be a digital version of like a production playhouse, um, console, you know, one that you would typically see on a desk and, you know, it has a lot of analog controls. This is really just bringing that to the iPad. Um, it does already run on Android and vision, uh, pro already today. Nathan: Those releases probably be coming out later in the year. Um, but Ed, I don't know if you can show something on that or if you can play some, maybe some Nathan: effects Nathan: from it. Eduardo: yeah, sure. Uh, not sure. Like if my effect. Oh, uh, it's just like, you know, it's like an iPad app. It's at least like iPad first. Uh, we are like working on, uh, no Android versions. And, uh, you know, if you also like, it also runs on a vision pro, but this is all like an Angular app, right. Uh, but uses nature scripts and these like handles like a lot of data. Eduardo: So you have like, uh, here's like a very like simple project. It only has like Eduardo: one. Yeah. Eduardo: Yeah. Eduardo: Yeah. So, uh, you have [01:00:00] like here, like mostly like, Eduardo: you know, the Eduardo: fixtures that, that I have, uh, which is just one. So, uh, and one is already like 20 pixels, right? Then, uh, it's quite like heavy, but here, like I can change the intensity of the light, but I also can change, uh, you know, uh, change like the tint. Eduardo: And, uh, I can also change the color if I want. So, yeah, it's cool. Eduardo: Yeah, Eduardo: so like this is Nathan: Oh, yeah, there you go. so Nathan: that, you know, that's, that's, that's, those are real time data feeds coming off, um, the iPad to DMX that's controlling the lights. And, you know, it's really, um, I mean, in terms of like the data throughput and your finger to the glass, um, it's very, very fluid. Um, and yeah, it's sort of the example of why you would use native script maybe, you know, cause in this case, a lot of service architecture was done around the data modeling in terms of the user architecture, the, um, the structures around the data models were already done in TypeScript and, um, you know, that's why you would Nathan: want to use native script. Nathan: Newscript in this [01:01:00] case, Eduardo: Yeah, and like for example, we're like we're we're JavaScript developers, right? So we want also to handle like our state in JavaScript so all of the state of this app is essentially done in JavaScript and we will eventually, you know, like find ways to portion it for example in like multiple workers because sometimes you have like This is mostly used in the film, but it's also going to, uh, we also plan, um, to be using like live events and you have no hundreds of lights of control and they, they can just lag or anything. Eduardo: So we are also like working, like partitioning this into multiple, you know, kind of like workers, uh, it may be not specific to, uh, inside the iPad itself, but also on, you know, physical or main on nodes or whatever, but it helps that the whole state in JavaScript. So if I, if I just, you know, use the same code and I share my, my root state, I'm able to pretty much break a one to one copy or [01:02:00] one to one like exact way of, of, you know, synchronized, uh, date. Nathan: the, the thing I'll add on that is we were just invited to Cinegear, uh, which is on Warner Brothers lot. Um, and they, uh, it's basically a cinematic, uh, conference, but, um, we, we were demonstrating this app there at a booth and, um, we were invited on set for, um, I don't know if this show is PG 13, but it's a sex lives of college girls. Nathan: It's actually nothing. It's not as bad as it sounds, but it's Mindy Kaling show on HBO. We were invited on that set because they use blackout this app on that set and they were shooting with it and filming that whole day. And it was neat to see it in that environment because he had, you know, tons of effects running on it. Nathan: They were shooting like a fraternity party house and there was tons of lights all around. You know, running the whole time they were shooting and yeah, that's, you know, this is the Nathan: kind of stuff that, namescripts use on for Eduardo: And one of the things that, uh, it's pretty nice is Eduardo: one thing That's also like Nathan: Keep Eduardo: Yeah. Yeah. Sorry. Yeah. There you go. So we also have like MIDI support. So this is Eduardo: like a Bluetooth MIDI, and I can just use it to control the intensity of the Justin: Oh, that's awesome. Eduardo: This is all Eduardo: like, you know, Natescript Eduardo: [01:03:00] just, yeah, we just call like, you know, the MK MIDI API, and then we assign it, and then there you go, like, we get like, every time this meets an event, we receive that in JavaScript, and I don't have here, but Nathan actually has one, so But there are also like a few of these that are, have like motorized, right? Eduardo: So when you change on the UI, it also changes. So you see like the physical board changing as well. Justin: Yeah, that's really cool. Nathan: Just the two, two way MIDI. Yeah. Just using core MIDI, you know, so that's, that's nothing. I don't even know if I'd call it magical there, but that's just core MIDI on iOS. You know, some of the platform provides, um, and, and we're not having to go around, Nathan: you know, the bend to use that. I mean, we're just using that in Nathan: TypeScript. Eduardo: And that's like the liberating Eduardo: part of Eduardo: an encrypt. Eduardo: Where, you know, if you want to do something and no one has done it, you don't have to go deep into anything, you know, don't have to go deep into, okay, how do I, you know, create a [01:04:00] bridge? How do I, you know, you just do it like with with what's available. You look into it, you know, the iOS API and then you call it. Nathan: It's a good example of that plugin question from a while back. You know, when the first thing, when the core midi, when midi feature came up is, Oh, was there a plugin to use that? No, it doesn't matter. Um, we didn't need a plugin, you know, to do that. Um, so that it's, it's certainly, I think when we bring midi to Android, then that question comes up. Nathan: You know, just to kind of bring this conversation back to some points earlier. Um, you know, cause we're talking about core MIDI, which is obviously iOS only. Um, so, you know, the app runs as it is already on Android, but for us to enable MIDI on Android, we'd want to enable that layer there. Um, most likely the way that we do that is through, um, just utility, um, layer. Nathan: So our utilities would probably end up returning, you know, Nathan: Android's MIDI system instead of iOS in that case. Andrew: Cool. [01:04:56] Conclusion Andrew: Well, that wraps it up for the questions that we have. Thanks for coming [01:05:00] on. This was a really fun conversation that got really in the weeds and I found it super interesting. So thanks for coming on Nathan and Eduardo. Nathan: Thanks for taking the Nathan: time with us guys. Eduardo: Yeah. Thank you. It was very Eduardo: pleasant to be here. Justin: Yeah. I appreciate y'all being here. And I'm just, I'm still blown away by NativeScript even today. I feel like it's like, it was really ahead of its time and I'm, I'm so glad to see it continuing and going strong. So appreciate all y'all's work. And I'm excited to see Justin: what you Justin: do next. Nathan: Thank you. You know, feel free to state where you want it to go next. I think that's a good way to conclude. If you feel like it should go a different direction, you want something else out of it. Um, it's a community driven project. Your voice matters as much as ours for sure. Justin: You heard it folks.