There's Python in my JavaScript! with Andrea Giammarchi

Welcome to Syntax. Today, we have here we're gonna try say it. Andrea Giammarque probably goofed it up, really cool guy from Italy, and he's better known as Wes Reflection on on the web. You've probably used 1 of his libraries at some point. There's 1 of the libraries specifically that I talk about all the time. It's called LinkedDOM, which is an implementation of the DOM that you can use server side, very popular in the web scraping world because you can you can parse HTML and then query it just like you were you would in the DOM. But I asked him to come on just because he's just an endlessly interesting guy, always working on interesting projects.

Specifically, right now, he's working on some stuff with running Python in the browser.

He's worked on microcontroller stuff, IoT stuff, lots of, like, implementing web standards in the browser before they have been fully available. All kinds of really neat stuff. I'll I'll let him talk about it, but welcome. Thank you so much for coming on.

Well, thank you for the Node present.

I I don't know where to start, but, yes, I do write a lot of code. I forget sometimes I already solve some issue, but I'm maybe I have again, and I forgot to look at my repository and and, 0II solved this before.

Yeah. I wrote all the polyfills.

If I want to give some background, I wrote polyfills for IE 4, and that was the time where IE 4 will not support try catch. So either you wrote a perfect polyfill or knew exactly what to tackle there or, mad things happen.

And then I 5 and all all the I e stuff. And, so at the time, I wasn't even doing front end. I was doing back end. And, so I started as a Pnpm, MySQL developer.

Yeah. And I Wes doing regular stuff, but then it was also the Adobe Flash or Micromedia Flash at the time as well, before. And so I was I was learning ActionScript because it was the cool the cool thing to do. Everyone wanted some magic animation or stuff like that from the web. And so I started providing bridges between the there was a a very weird and primitive FFI between JavaScript and ActionScript, but you could actually drive stuff from JavaScript to to to reassemble somehow. And then, they were lacking standards, and so I started writing politics. So every time I write something in that, it's actually to solve a real problem I'm having, and it's not we're fun. It's it's because I need that. And when it comes to LinkedIn, because you mentioned that, at the beginning, it was because I I wrote this UHtml, library, which is super tiny, super nice, and it makes you create reactive UI and by standards, like template literals. It's Node to HTML or many others at this point. But at the same time, I wanted to have the same on the server. And so I thought, okay. I need the Deno implementation and I started using JS Deno. And JS done started some some sometimes it was too slow. Sometimes the document was too big. Sometimes I had this kind of issues, and I thought, okay. If I want to have AAA lighter Node, what can I do? Another time, I thought, let me remember what what's computer science saying about the leaked list and stuff like that. And I created a leaked on pure experiment and turned out to work really Wes, and it was actually pretty fast too. So III wrote it to basically solve 2 issues I had. I wanted my test for USTMA on the server to be super fast. And also I wanted to to have the real thing of the server too so that I if I have a page that the user already requested, out of a session or anything, I want us to change some data or update the list and just boom. If you ask this that page again, it's there. And just the man minimum amount of changes happen behind the scene on the on the Okay.

Yarn of done. And so and that also worked Wes.

But then the library became somehow popular, and people started asking more and more and more. And I was also interested into adding custom elements, which were were nowhere in in at the beginning. I don't know the current state, to be honest. And so it became more standard than initially Wes meant to be. It was meant to I I mean, I didn't mean to to write a replacement for JS DOM, but a lot of people are actually using it for all kind all sort of stuff, all kind of stuff. And Yeah. And to me, it was actually great because it means it works, but at the same time, a lot of responsibility

on my shoulders. No kidding. It's 1 of those projects that Scott just got like, I think, comes sort of runs away. It gets really popular, because I didn't even realize, like, the reason you had had written it so you can write custom elements or or web components. The reason I found it was because I needed to run JSDOM in a Cloudflare Worker.

And at the time, JS DOM didn't run-in a Cloudflare Worker. I don't know if it does anymore, but I it was many years ago, and III probably install at least once a month. It it's better than that. You can use basically so the idea was this isomorphic

dream between writing code that runs everywhere, front and back end. And the thing is that there is a worker dedicated export and that runs in web workers, meaning that it runs also on service workers. So you could have an Sanity around time dynamic thing, of offline dynamic thing that runs out of service worker. You just create and generate Deno with the same for as a as a response with the same exact Node and logic that you had on the front end. And so you can validate on the front front end works, and you can test on the back end too. There is 1 little caveat there. The high threshold story is still not fully implemented in UHtml because every time I try to implement some huge library or framework comes up with a different idea of what hydration should be. So Solid JS, React, they all are doing hydration in a in a is a slightly different way, but still the goal is the same. You know? You just provide the minimum, amount of, HTML that works. Hopefully, even without JS, but then you need to hydrate only the parts that need hydration like events, ESLint and list stuff. You don't wanna rerender the whole thing. Otherwise, somebody from the, start don't stand those or web Scott those will will kill me if I do that. But I'm doing that because it's so fast to use HTML. So I'm just, like, okay.

Page is there. I can rerender everything and boom, it's there. But that that can be a problems if if the document is huge or especially if you start typing in an input. I I don't want to lose that that thing keep going on. So I don't Yeah. You can't destroy all that. Yeah. You don't exactly. So and, and also you already scrolled and rerendering my Wes up the scrolling. So all these kind of things need more, attention from my side. But right now, I'm focusing on something else. And so I I wish I had infinite amount of time to to solve all the things, but, yeah, Pyscript is the is the current project I'm working

we'll we'll talk about that just a sec. Scott's gonna do an ad read here. Well, before we get into that, it's been 2 minutes into the show. We already, had the words action script ESLint Internet Explorer 4, which is incredible.

I love how you said that you created this to solve your own problems. That's something we talk about all the time, that my problems most of these days are with bugs in my code.

So if you have bugs in your code, head on over to century.i0 because it makes it super easy to solve all of your errors. It tells you where the error is, and it lets you fix it effortlessly.

I'm just adding in, today, Wes, I added in, cache support so you can see cache hits and misses with our Redis cache because, we we haven't had that in there, and that's been a a feature of Sentry for a little bit. Yeah. So I just added that in there. So if you wanted to be able to solve your bugs and solve your performance issues, head on over to century.ioforward/ syntax. Sign up and get 2 months for free.

Alright. Now we can get back into it. Yeah. So first of all, where do you work right now that you're you're able to always be venturing on the III picture you as a guy who's sorta on the edge of of what's coming, you know, browser standards, new things that are happening. Often, you're writing Node so you can use the new things sooner than than they're available.

That that's a privilege, to be honest. And and I love it because they get to work with the most recent stuff. And and, honestly, the the project is about working with the most recent stuff because you can name any modern web standard, and we are using it. So, like, atomic, shared data buffer, workers, service workers if needed, remote Wes assembly execution. All of a sudden, it's crazy. So we're doing stuff with that. I don't know any other project that is covering this kind of tech oh, putting together, all this kind of technologies to, to do what we do. And it's not just us, to be honest. We are using WebAssembly based interpreters like and MicroPython.

They have their own community, their own effort, and they integrate so well with the browser that they can you can manipulate the DOM directly from from from Python. And that open, a world of possibilities.

And, also, it requires some orchestration when it comes to garbage collection because we don't have yet in WebAssembly world. We don't have a a central. We got a bunch collector where the the browser can hook into and any other WebAssembly targeting programming language can also use to understand who's using what, when should I remove, erase that thing from from from the Python side or from the JS side? So we also use finalization registry.

Let me let me stop you there.

You're running Python in the browser. That's what you're working on right now, this thing called TypeScript that can run Python in the browser. Like, we'll we'll get into how you do it in a second, but let let's talk about what it is and and why you even wanna do that.

Okay. So the the why, it doesn't come from me, but I the reason it comes from the company, which is Anaconda. And, they they are huge in in the Python ecosystem, and they they provide the toolings and stuff. So the why in in their words, but also is what I believe is that a lot of people just learn Python, let's say, university or even kids that are that are courses training for because it's it's 1 of those languages that is super easy to start with. And eventually, it has its own caveat like every other programming language. And, if you wanna really go deeper into all the details Mhmm. There there are messy things like in JavaScript as we know. And, but, yeah, still is super known and, is 1 of the most learned programming languages out there. And and we thought, how about everyone can use it, so you don't you don't necessarily need to go into this huge ecosystem that is JavaScript and the the entirety of the web. And you just have a way to write your code in Python and you wanna reflect some data. You wanna especially if you wanna manipulate data, there are there are lovely, wonderful, libraries that give that for you, like the math botlib and many other packages out of the box. So for for data scientist JS wonderful.

For people working with anything really data related is is is superb. They actually know what they are doing. Maybe if I have to write a demo quickly, I I don't know what to do because I'm not really into that data science, but they they Yarn. And they they find themselves instantly able to provide a web page that anyone can see and crawl the data or click something or something or I've always been impressed with with the Python ecosystem because it's

it's huge in people learning to code. Right? It's not just like like, JavaScript is huge with web developers. Right? Where Python is huge in data science, it's really huge in AI right now. You know? Like, most of the entry to AI stuff and most of working with AI models is done in Python. Right? We've we've talked about being able to run it in JavaScript and interact, but if you wanna get

bare bones to it, most of that is done in Python. So it's Yeah. It's, like, quite the ecosystem. We're getting there. We're getting there about AI. Yeah. JS we're missing so still because we are working on most, modern technologies, we are missing just a more widely usable web GPU API because otherwise, we cannot, run models.

I mean, we we could run models in by other means, but it's not gonna be nearly as fast as WebGPU. No. No. I was playing with some,

WebGPU versus WASM implementations the other day, and it's so much faster with WebGPU, but it's it's still early days where you can't really use it yet.

There JS, Chrome and Chromium and Edge. They ship a Chromium thing, which is AI, namespace, their own thing, and then then you can create, that you you have to download. So there is a a setup to do first, but then you can use directly their their own, is it GitHub Nano or something like that, a model that you can query and ask things, and, he he answers back. I wouldn't face, like, chat. He answers in in in markdown actually, And that's also fun because you can get that markdown shown the page. And so you could create something like a a little chat Wes you talk with a bot. But it's early days, like I say. Yeah. Although it's you you can already explore this field and see how it works. And we already created a minimal MicroPython because it's just very fast to to bootstrap. So MicroPython query, Gemini AI, producing some result, which you don't have to use MicroPython.

It works just out of the box with JavaScript once you Yeah. On the setup. But it was instantly for people like, oh, wow. With Python, I just write these 2 things that I'm querying or interpreting a Huddl, and it's coming with JS far as with that account format and show on a web page because markdown in console is not really great. And so, yeah, all these kind of things are are super cool and, I think.

I feel super lucky to to be able to work with all these later things.

So what I still don't understand why is is PyScript trying to run Python in the browser? Like, what what are the needs for that? Well, like I said, you you don't need to learn a new thing. So you write your Python Node. You know Python code. You know Python syntax. All you need to know eventually some extra DOM API if you wanna or maybe you could use JS libraries. For instance, we have you HTML is working in in MicroPython 2. They're missing the template story, though. So that's something that hopefully is keeping soon. But it it's just about keep being friendly with the with what you what you know and what you know. And then it's also if you want a migration pattern, so you start like that. And then as soon as you need to more from the DOM or from the web space or some API that is only available on the web, in that case, we'll migrate slowly from Python to JS and learning also, what are the differences and how it works. And so that's 1 thing. The other 1 Wes it comes with microcontroller is that you can actually test and validate whatever you you're doing with MicroPiter on the browser before flushing or, by serial port before sending all the all the things to the board and let the board do its own things by itself. So this is another way to to think about, okay, I want to have my, again, testing environment that is actually reflecting what's going on on the server or what's going on on the microcontroller.

And so we need again some mocking API in there, but there are mocks for, for microcontrollers.

And so this is also Scott a kind of parallel universe where you type everything in your browser out of a terminal, which is running in your browser with a Mhmm. Without, with a REPL with a proper REPL. And and you would see results on the DOM if you want, or you can just say, okay. Now flush the device and, and let the device do the thing. And I'm sure the device is is working because testing directly from the device

is a bit more painful than than just Really slow. Realizing what's going on on the web. And, Wes, you can probably understand. We we have a shoehorned JavaScript into the Vercel, so getting Python onto the browser isn't really it's kind of just the opposite of that. Right? Yeah. It's outside bound. I know. I know.

Yeah. So people are able to make applications.

And instead of writing client side JavaScript, they're writing client side Python?

If they want, they can. Yes. But also so that's, let's, be explicit.

Node JS well as MicroPython, they run also in Node. Js through the Wes assembly. So these are just slightly different ports.

But you can if you want to execute or evaluate some Python Node, some for whatever reason, you can take that, run into PyTorch. Interpreter, which is the the is based on CPython, which is the the real Python behind the scene Wes you stop Python in your desktop operating system is is basically the same. So same module, same same packaging, same same everything.

You could do that too. And I think I don't wanna make names because I don't remember who exactly is doing that, but there is some cloud that is offering also, Python as a worker. And so you can just bootstrap your worker, and that's gonna run Node, which is still 1 of the interpreter we are using. So, again, you you you can help that, and eventually, you call that, use that.

Also, let's say, with a service worker and create your offline application that is still using Python behind the scenes. So, again, if you wanna if you wanna do that, you can do that. And the funny thing is that PHP is producing a Wes assembly, and I already played with it. It's it's it's funny because they echoing, and needs to be appended as a inner HTML or AAA HTML of the page, but it works. Wes have r.

We have, which is Lua.

So we have a lot of programming languages that are actually targeting the web for the pretty much the same reason. So they want to provide Sanity to write your code. And if you wanna display something on the page, you don't have to deal with the that the desktop is offering or the that any specific package is using. You just show on the page whatever blob you created, and that becomes an image and or a canvas. We can draw. You can make the games. You can do any sort of stuff. So I've seen games.

They Yarn rendering through Wes, but you you can do also this kind of things. And these people are just, you know, with Python, and so they they just faster there. And so it's Yeah. And I replied for as many people as possible, super especially for people that know knows Python more than than JavaScript or or Totally.

Or if you you have, like like, a whole bunch of infrastructure that's already bit written in Python, and you need to be able to like, a lot of applications, not so much anymore, but, like, lots of legacy applications are written in desktop.

Like, they might be written in Python. Right? And then all all of a sudden, you need to be able to run that you need to compute something in the browser. Right? Like, maybe it's a a complex, mathematical equation, and you don't wanna have to rewrite that implementation in JavaScript because now you're you have 22 things that you're sort of trying to maintain. So you can just run it in Python in either in your Node app. Right? Like, you you oh, our our main app is now in node, but we still have to kick out to Python for some of these, or you can run it in the browser. Or in your mobile phone because it works even there. So Oh, yeah.

So I'm I'm curious about how you do this. Like, you mentioned there there's Node, which is a Python distribution for the browser and for Node. Js via WebAssembly.

Can you explain first, for anyone listening, explain what WebAssembly JS? And then 2nd, like, how Yarn you able to run different languages inside of of JavaScript?

Right.

So remember I started talking about ActionScript? Yes. It was produced in SWF, which was, basically an intermediate language to instruct the, the flash, runtime at that time to to do things and show things or intercept events and so hook, the the that code with the rest of the platform. In that case, the platform was the was the web page. Web assembly is very similar in concept. So you don't really write it manually, but you can target it as a runtime, let's say. It's a it's an intermediate runtime that then runs in the browser, sandbox, and everything. So it has a lot of insecure. Let's say, you're not just pawning a Python thing that could do whatever you want on your server. You're just using some memory. You allocate some memory to run this WebAssembly runtime. And so it's it's supposed to be as fast as native compiled languages.

Unfortunately, that's not always the case because there's some specific CPU extension that maybe is not, usable, or is not always available. And so this kind of things. Well, basically, you your code becomes a list of instructions, and your code has to be, let's say, native. So scripting your web assembly makes very little sense. But, any anything else that either has a very tiny and simple, GC model like Go. I think Go can produce web assembly. Rust can produce web assembly.

Pretty much c c plus plus and every out in the, all of you. You name it. So any native language can target actually word assembly, including Python, which is CPython behind the scenes. So it's mostly c c programming language. And and also MicroPython, which is also I think it's c because, it's it can produce a super tiny, like, in terms of few kilobytes, and you have a whole environments in MicroPython where you can inter interface with the, sensors or displays or do whatever you want, buttons and and and everything else. And so the WebAssembly in this case is portable, meaning that you could use the same exact same WebAssembly blob, and run it through the browser, or through the server. It can be Node. Js. It can be anything else. What is it doing this WebAssembly JS exporting a module, and you define what, functionality the your code should expose to the outside, which can be usually pointers, buffers, integration, 14 points or so. And and you can communicate, in and out with this with this Node, which is at that point of a WebAssembly blob. But also, cool enough, you could have source maps for WebAssembly so you can actually have an idea what's going on. Although, JS, the bug in WebAssembly itself is something that fortunately, I don't have to experience, but I'm sure people in pilot, team, they they they do that at some point. And also

So with web assembly, you're saying you don't need to create, like, a x 64 version of something like a like, for example, we use FFmpeg on the syntax website. And, a WASM implementation of FFmpeg, it's a little bit slower, but the the benefit to using the WASM version is that it would run-in the browser. It will run-in Node. Js. It will run on on the server. I don't have to worry about where this is running, where normally, you'd have to, like, make sure you install the correct version on that operating system. With WASM, it's just this WASM package. It downloads the thing, and it can run it absolutely anywhere that WASM is supported.

Yeah. And also any architecture. So that's that's also very important. Because on the browser, you just produce a a WebAssembly. You don't care if the browser comes from, macOS, JS Window, is Linux, anything else that you you might think about. So that's a huge advantage. So it's very portable. That's that's for sure. You need Node, WebAssembly runtime able to understand what's going on, but I think browsers are pretty well aligned in there. So we never had surprises where some specific WebAssembly thing or method, all of method exposed by the WebAssembly wasn't working somewhere else. So it always works. So that's a huge win, I think, for the for the format. And like you said, it's not it's not as fast as c plus plus or c. But, it's close. You know? It's, it's a matter of trade offs, I would say. And also maybe the WebAssembly final blob is not ideal for the web because it can be huge. It can be in in order like, I think, is 280 kilobytes.

But if you think about how much you can do with that, it's nothing. It's nothing.

And the 1st time if your metric is how long it takes to have that thing running already in my browser for the 1st time where there's no cache involved or anything, well, it's gonna take longer than you want. Yeah. So that that's another thing they are working on, I think, which is the ability to have modules in the WebAssembly system. So you you you can have instead of having a huge blob with everything in it, you can start sharing modules. And so the caching system works, and so you have pluggable and composable, blobs, which will be huge, I think, whenever that happens.

What's the most exciting thing to you, I guess, about WASM? You personally, not necessarily professionally.

Right now, I'm not I'm not targeting WASM. I'm just using it. So for me, it's a huge thing that I can do that. My favorite thing whenever that happens is that it will be the somehow orchestrated or distributed garbage connector. Because at that point, it doesn't matter anymore what programming language you are using because they can all communicate through this thing that can orchestrate memory for for for for all the parts. So at that point, you don't need all the complexity that we have right now through shared, well, shared with our buffer for another reason, but the finalization already is with them. So the fact that you need to track manually what's going on, what's coming from the the other warp, the world should be kept alive in your memory and what should be released or when you release something from your memory should communicate.

So this dance can be if you think about especially if it's done through WebSockets or through client server communication in the long session, it can get lost. So you don't want that. You want somehow a way to understand when things can be freed from all the sides, and that should be probably a WebAssembly thing or feature, but it's not there yet. So that's the thing I must I must excited about because I think it will make a lot of people happier, and there will be less, war again between programming languages because everyone can write something that target that and can expose functionalities through that. And so at that point, they've just a matter of orchestrating.

A bit less still having full freedom in which language is doing what, and the will become some sort of the universal, intermediate thing for everyone. And so, yeah, that that that's to me is exciting. But at the end of the day, everything I'm doing is exciting because it's really writing with the most futuristic things I could think about, 10 years ago or more. And so for me, it's still and and still a constant learning curve because the it's it's new and changing pretty fast. So Yeah. These, these are all the thing so never boring.

We just finished up an interview with the folks from Prisma, and they were explaining how they built their database engine in Rust, and then they just they access that via WASM. I'm curious if you have any other examples of something that someone might not understand is using WASM in their application.

Well, I mentioned SQLite, and I'm using SQLite in a way that you can it runs in memory, of course. But Mhmm. Because it's SQLite, you can also ask to give you the a snapshot of what you're doing.

And if you have a way to store that, let's say, IndexedDB, you can have an entire offline web application capability because you you have a database which loads bootstraps with the data that you saved the last time. And then whenever you update data, you send it back, and it's all local and also it's persistent.

So at that point, you you have a huge, advantage of using WebAssembly because you have a full database and your relational data JS there you can use, and you have all other bricks to connect and do whatever you want.

Replication, maybe it's for JS Wes assembly is not a topic, or it could be, but it's gonna be more complex than than than it's needed. But for specific things that can run as a stand alone web application or anything website related where you you have your own IndexedDB as a user surfing that thing, and you can query and you can update and you can change stuff. And, so it's it's super powerful if combined with something else. By itself, WebAssembly does nothing. So that's the thing. You you need to you need to have a use case for that specific technology or that specific project. Like, for database JS obvious, but then there are or FFmpeg.

So you don't have that from the browser, so you want that. And that's another use case. But surely, it's not just AAA magic wand where where you can do everything in in Wes assembly because sometimes it makes no sense to have everything. Yeah. It's it's 25 megs for anyone listening. Like, that's

that's huge. You you would really have to think, okay. I'm building like a like a desktop video editor Yeah. Where I I don't feel like shipping a version of FFmpeg, so I'm gonna run it through through Wasm. So it's, in our case, we use it server side, so it's not that big of a deal. But if you were to download 25 megs in the browser, that you would have to be very sure that that would be worth it.

But, you know, maybe maybe there are other use cases like Electron or those apps that you won't ship and and that WebView. And with the WebView, you can do all these things, and things are already shipped within the installation. So the 1st time you install that is the time you already have all the things, in it. So in that case, also, maybe makes sense. So it's worth it. So you mentioned WASM run times.

Any thoughts on on WASI, which is this idea that or maybe maybe you can explain what it is. Are you familiar with WASI?

So I know that it's a different slightly different target. So it's like Emscripten, which is usually the tool that people are using to produce WebAssembly.

Emscripten, as far as I remember or know, it targets Wazn, but Ruby, targets Wazee. I mean, it's probably a huge detail behind the scene, but from consumer, it it doesn't really change much. So you're still Scott in a module as a blob, and you use those functionalities.

So from user perspective or from my side, when it comes to interpreters, I can boost Ruby as well. And I don't do anything different from bootstrapping Pyledite or MicroPython or Wasmun or Lua and R and I and or even PHP or Quick JS. I don't do anything different. So it's something that I'm sorry because I'm not answering, but probably because I don't know all the details behind the scenes. So I cannot provide a proper answer. I'm just saying from a consumer perspective, unless there is a huge of the advantage in in speed and size, final bundle size,

I'm I'm not sure we should care too much about it. Okay. That's a good that's a good answer. So I'm curious about IoT, Internet of things. Right? And and you mentioned microcontrollers earlier.

What's your experience working in with those types of things? I tried

multiple times to create a kiosk, based Raspberry Pi system. So something that just bootstrap into a full window web view where you have full control of what you can do with that hardware. So you can query GPIO or set different things, through the hardware. You can have a database behind the scene, and you end up with a tiny portable thing that you can you can use for, I don't know, right now, IoT that you you for for consumers, so it's something that you see a panel in your light switch and the panel says something or even the temperature. So that's interesting and cool, but I want to have full control of the of the whole hardware behind the scene. And so with the Raspberry Pi, it's it's pretty easy or any other board, to be honest. It's it's pretty easy to bootstrap that and have a full control through the browser. But I always miss the the primitives to the weather. And to the weather, you need, atomics because with atomics, you can create a proxy that is synchronous. I can synchronize the state between your code in a worker and actually Node JS or BAN in the server. And so you just type something, like, let's say, Bos Scott CPUs and you invoke it and you have instantly an array of all the CPUs that you have, that Wes impossible before. So my previous attempts somehow always fail because something was missing. But right now, we have all the primitives to to do that. And with a project of mine, it's called coincident, and coincident really open opens the work between cross browser and anything else. So JS we are using it to enable virus runtime and the interpreters in TypeScript project 2, but you could also drive entirely in your own sandbox on, like, your own device.

The whole Node. JS interface, namespace, anything you want, so you can just do that, and that's promising.

So me working with this kind of stuff is always, let's say, a hobby. I I don't have concrete like, I don't have created yet a product that I can say, hey. Let's kick start this. Yeah. Wes that a goal of yours

to create a product ever, or are you just always going to just be exploring the space?

To create a product? Yeah.

III think 1 day, I will be able to. Right now, it's, something that I think, okay, maybe maybe when I have some free time, I try to hack around some something and see if I'm happy about it. The thing is that I'm never super happy about it. So it's always like a constant growing experience and research to to find also what's missing. Because these days, there are so many ideas and so many projects and products out there that, yeah, it's hard to compete. It's hard to be fast. I know I'm I'm also working full time, so it's a and Yeah. Yeah. I don't have much extra time. So And, well, let's talk about

JavaScript in general. Is there anything in the language or in the browser that or maybe even on the server that you wish the language would have?

Yes.

I think I every time I do, I write

an issue or a

in Deno 39, a forum and not forum. What is it? Is that Discord? No. It's not Discord. It's, well, anyway, they have a place to talk about all these the crazy ideas that are missing.

1 of the latest is about ESX, and ESX will be something highly inspired by JSX, but actually better because it's not strictly coupled with the, react primitives and not strictly coupled with the with the features that JSX offers and get that Scott nuked. So that's something that I'd love to have.

You guys are really excited for about a minute there. Yeah. Yeah. Hold on. What? Yeah. Yeah. Yeah. There's there's rarely a happy ESLint.

Yeah. Because I don't know. Maybe it's me the way he proposed those things. I don't know. But to me, it was super clear that everyone loves JSX, CPAC, and the fact you can just write trees doesn't have to be necessary, doesn't have to translate into into HTML. It can be actually anything. And you see JSX is indeed is JS everything you like because if you think React Native, you're still writing JSX, but it's targeting in a completely different platform. So possibilities to have this intermediate XML like tree representation that doesn't really couple the the the tree as it as it used to be with the AE 4 x, which Wes a implementation from Mozilla ages ago, which is is gone. But that inspired GSX. GSX inspired ESX, and ESX could be what GSX has never been.

But Node. So excitement, you're gone. But that that really something that III would like to to to see.

I'm I'm very curious about that as well because, like, quite honestly, for me, things that are missing is some sort of, like, templating language, kind of like, JSX, but maybe a little bit better. And then the other 1 is just, like, some built in reactivity.

So I know signals is is kinda being talked about. There's a proposal for adding signals.

What you've written UHtml.

You probably have thoughts on, should we have reactivity in the browser? Yes. Absolutely. So since Wes I'm a huge fan of the proposal.

I worked with Dan previously, who was 1 of the proposer for for this, stand out. And I think I I don't know why it's stuck because, it was announced few months ago, and I haven't seen much progress in there, but I already have in a used temp used HTML. I have a slash reactivity or reactive implementation where you can use a solid JS signals, pre act signals, my own signals, or the current standard signals proposal.

And it all works wonderfully because at that point, I explore with React alternatives.

It's a bit too convoluted to have all the effects, state, and things with the template and without having had any help from tools. And so it works, but it we can spaghetti and ugly pretty soon. Well, with signals, you just have you pass down the thing, the the the the tree or your dumb, your fake template dumb. You pass whatever you want. And Wes of that changes, which could be either just typing an input or sliding something or clicking a button. If that change, you have atomic reactivity.

So you can you can actually have fine tuned reactivity on before that specific part of the page and that change it. And it's much easier and it's actually, I think, also faster than just a huge app to render where you have to do this atomic, change. Mhmm. And that always happens because when you set a state and the state is in the outer container, it's it's gonna propagate down. So Totally. Yeah. It's, signals, I think, can be more, fine tuned in in if that makes sense.

Yeah. That's we're big Svelte fans here at Syntax, or we built the Syntax website in Svelte. And if I'm not mistaken, Scott, that's how Svelte works. Right?

The the latest well, okay. So Svelte before in the past has always been the values are reactive. So before, not reactive or, not signals based. But in Svelte 4, yeah, you don't get component waterfalls where components rerendering. You have values tracking, and those values update. But with Svelte 5, it is entirely signals based, and you do have that fine grain reactivity out of the box in addition to, yeah,

not having component reloads all the time. Yeah. Oh, that's gonna be great. I'm I really hope that this this makes it into the browser because once we have this idea of signals like, imagine the Svelte version just implements native signals. You know? And then Yeah. That's the correct yeah. Can take a library that just accepts a signal, and that library doesn't have to be a like a Svelte version.

So, that's the entire premise of it of the, the Svelte version of it JS with the intention that Oh, really? Yeah. Because Svelte is you know, that's the disappearing framework. Right? That's the kind of the idea behind it. Yeah.

What are your thoughts on, like, server side? We're seeing a lot of, like, standardization on web Wes, web response, fetch APIs, things like that. Do you think, like, that's the the API to write servers? Do do you write a bunch of servers? Have you in the past? I'm sure you have.

I do. Not not as much as I would like to, but, I do. And, I'm I'm super interested in 1 which is using or even Deno is is using as much standards as possible.

Yeah.

It feels right. So it's still that isomorphic idea or dream that you you know, you want to respond to something that is fetch. So on the browser side, if you forget, ESLint channel ever existed, you use fetch to fetch stuff. And Yeah. The API for service worker, you you you add an event listener, which is fetch. And so it's all about fetch. You know? And so ban has, you create a server in a few lines of code, then he has this fetch.

And the fetch gives you the the current details about the request, and you return a new response. And so That's that's it cannot be easier than this. And the same response you can use on the client Node. And, also, it can get easily complicated if you wanna do more complicated things like streaming, and and now we have compression stream.

We have blobs. We have our buffers. And so those details are usually eased out by libraries and and and good good documentation. You know? So you don't necessarily need to know all that. But if you wanna if you wanna return a new response from a fetch or for anything else, you you return a new response without to run the status and some header and some content. And that that's pretty much the end of the story. So I don't know if it's the Wes, the server, or if it's actually I don't know if it should be a goal to have a 1 to 1 API browser on the servers because the the the use cases are completely different. And also browser APIs are always asynchronous.

For people on the server side, it's like, nah. Don't worry. I don't want to wait. I don't want to work on anything else. Just give me give me the, I don't know, the the the the deep zip compression already. I don't want to wait for a compression stream to tune up all this kind of extra overhead that it's not needed. But maybe that's that's why libraries can help there. And so you should have a minimal that is using primitives available in banning, in Node, and on the browser, then you have a tiny library that is model tested, but it's single purpose. It works everywhere, and maybe anyone can use it and just move on with the next issue.

Awesome. Are you a TypeScript user?

Wes and no. Yes. I can I can read it? I can write it. Node. In the meaning that I use, JS doc Wes.

Okay. I write TypeScript into JS docs whenever whenever I can. There there there is 1 tiny issue I have with TypeScript than what I do daily. I I think 60% of the Node that is running right now is based on proxies, and proxies don't play super well with TypeScript. So it's not giving me much in return. So but when it comes to writing some documentation for the next developer that is gonna help me with the project or the the the future contributor or the future myself.

I mean, the future me is seeing what's going on. JS Node PS is super valuable, and I recommend anyone not using TypeScript to at least try to use JS dot PS. There's Node feature Sanity, so there are things that you cannot do. But recently, I wrote who wrote, like, you can even define multiple overload for the same signature and same function, sorry, with different signal for for the overload. So there are more features coming, every time the TypeScript updates, and, and it's becoming more stable, and you can import types from other files without needing the DTS file there. So it's become more powerful.

So that that's, that's my answer.

Yes. It's wonderful when it works, but it doesn't give me much in terms of feedback when it comes to proxies. It's, it actually makes things more complicated. So I just want to write my my little JS doc that, the compiler might complain that some instruction in my documentation is not perfect.

Yeah. Sometimes I don't care and just move on and test stuff that it works, and, that's by my flow.

Beautiful. Yeah. I often wonder if we will see like, will TypeScript eventually give us proxy support? Or another 1 is people wanna be able to type what is thrown. Like, you wanna type the error that is thrown from a specific function.

That would be really nice. You know? And I often think like, do you think TypeScript will ever get that, or are we going to is the thing after TypeScript is what we're gonna get? Is it gonna fix all those issues once we've had 15 years of saying, alright. TypeScript is good, but

there's something else. There's also a proposal in t c 39 about types embedded in in JavaScript, but it's not nearly as powerful as TypeScript is right Node. But that will be something. And I think Node. Js already shipped with a flag with a special flag where you can just enable, type type hints. I I don't remember how they called it, but it's basically you you writes it looks like TypeScript, but then it's not using TypeScript to to transform. It's just ignoring those code those those hints, and the code executes as if they were never there.

Yeah. The the proposal is called I think it's types as comments.

Yes. Where they are just going to reserve parts of the syntax for types.

But what they're not going to do, or at least what the proposal is right now, is they're not going to propose that t c Node decides what types in JavaScript look like. It's simply just you may put whatever you want in this little spot.

And I'm curious JS once that lands, do we start to see somebody come out with a new version of TypeScript being like, alright. TypeScript, the good parts.

Do we see a new version of that? I don't know. I'm I kinda hope so, but we'll see. To me, the main concern is interoperability.

So you have a file that maybe, let's think about BAN. JS for instance. Sorry.

BAN is able to digest any sort of pnpm. Like, it can be common. JS. It can be, JavaScript module. It can be TypeScript.

Yeah. And we're wondering if they Bos the they they assume what kind of file is what by, just checking the extension or maybe checking the Node, what they're gonna do? So how much more complicated is to be sure that the code you Yarn looking at produce exactly the same output if it's true touch screen that maybe did some change conversion in the process or just native JavaScript that just ignore everything else. And also that code that you can copy and paste, what are the chances that the it won't work in every Node? Because if your Node is using TypeScript and it sees types, it will tell you, hey. Look. This is not this is not working. This is not right. While Yeah. The same goal with the just in a regular editor that doesn't understand TypeScript will probably throw errors all over the place telling you this syntax is not allowed. And then the same code again in Node. JS, just run without any Yeah. An issue because the types are just gone. So this is like early days, but I think we will we will, at some point, hopefully, converge into AAA unified format that works everywhere.

But it will be sketchy at the beginning, I think.

Yeah. IDEs and all configuration and all the kind of, ESLint rules. So, you know, this kind of stuff. And, yeah. Yeah. That's that's my main concern. Everything else is awesome. As long as it moves forward and, it's cool that Node. Js is is playing this testing platform right now for that feature, and, TC 39 probably is happy about it. So that would be feedback, maybe.

Yeah. Absolutely.

Awesome.

Let's move into the next section of, the episode, which is Wes have some sick picks and shameless plugs.

Did you come prepared of the sick pick?

I was reading quickly about the sick pic. No. Yeah. I don't know. So I'm the sick pic about myself. So it's it's boring. And I'm I'm just, extremely I'm obsessed with, minimalism and little things so much that I I think I bought all the all the mini all the mini boards. I don't know if I should have those. What sorry. What are these? Mini

Oh, mini boards.

Oh, no. So micro He's holding he's holding up microcontrollers.

And which microcontrollers are these?

So these are mostly ESP 32 based.

Okay.

This is, Raspberry Pi Pico.

Yep.

Sorry. Raspberry Pi Pico, not Pi.

This is, Arduino Nano.

This is this is awesome. It's so tiny, and it has everything. So he runs micro Python. He has an LED where you can do things with different color because it's RGB LED.

And he has a Wi Fi, so you could use these as a even as a tiny WebSocket server or I I don't know. And you could connect to anything else. And they love a little things like these. So this is a you you won't gonna read it, but this is a SD card with 400 gig gigs of memory. My gosh. It's not my god. My dream is to have Node day, this is a pie 0. So a pie 0 with a tiny screen that Wes, like I said, Wes you just bootstrap it, you start clicking things, and, and it tells you whatever you want, or you just connect to the TV and you watch something. Or I don't know. I'm a manicure of little things, and I'm collecting too many little things. But

I man, I love that that whole area. I've dipped into the the whole microcontroller thing myself a couple times, and we had, Nick Herr on Syntax Node 6/28 talk about running specifically running JavaScript on the ESP 32.

It's a wild, wild world. If you ever need another hobby Yeah. Certainly, that is a that is an enjoyable 1 to dip into. There is an Espruino project which is running on the microcontrollers too, and the the that's, that that's super cool. But, unfortunately

or fortunately, I don't know. MicroPython is running everywhere, literally everywhere. And there are, Wes have students at Tufts University in Boston that they are they are building with and and with microcontroller, and they are playing around with the Lego spike. And it's so fun because it feels like stuff for kids, but for if you know a little bit of programming, it becomes instant fun for everyone else too. Yeah.

That's great. Awesome. And the last thing we have here is Seamus plug. What would you like to plug to our audience?

III rant way more than I should on Twitter, but, I that that's Wes I read a lot of stuff, and sometimes III make some decent comments. Not always, though. But, definitely, if you wanna see what I'm doing, follow my latest projects in GitHub because, it's gonna be fun. And, I would like other people to understand what you can do these days with more modern, APIs and and and technical. Yeah.

And not not just it doesn't matter if it's Python or JavaScript or the web in general or the server or the ESLint, but so many things that are moving forward and fast, and, it's it's super cool to maybe have this tiny reference. You you see this little project. You clone it. You test ESLint. Now you think, ah, it's Scott. And then you build the next cool thing that I never thought about, and I would be able to. Totally. Yeah. That that's what I like about following your GitHub and and your Twitter. It's just you're you're always looking at

what does the future look like Yeah. Digging out these little nuggets of of interesting things. So, yeah, certainly check it out. We'll put links in the show notes as well. Awesome. Thank you so much for coming on. This was fantastic. I learned a lot. Amazing. I'm really excited about just just everything, and appreciate your time.

Thank you for helping me.

Yeah. It was great. Thank you so much.