Better With Rust
JavaScript Jam Live discusses why JavaScript developers should learn Rust, its empathic compiler, and previews upcoming fall dev conferences
Episode Description
JavaScript Jam Live discusses why JavaScript developers should learn Rust, its empathic compiler, and previews upcoming fall dev conferences.
Episode Summary
This episode of JavaScript Jam Live covers two main topics: the growing role of Rust in the JavaScript ecosystem and the fall developer conference season. Guest Ivan (referred to as Yvonne) shares his experience transitioning from JavaScript to Rust, explaining why Rust has become the go-to language for JavaScript tooling like SWC, Deno, and esBuild. He emphasizes Rust's uniquely "empathic" compiler, which not only catches errors but actively guides developers toward solutions, and argues that JavaScript developers can become productive in Rust within four to six weeks of intensive learning. Key challenges for JS developers include adapting to immutable-by-default state, the borrow checker's ownership model, and thinking in types without an escape hatch like TypeScript's any. Despite the learning curve, Ivan notes that once the Rust compiler accepts your code, incidental bugs essentially disappear. The second half shifts to fall conferences, highlighting Jamstack Conf, Next.js Conf, ViteConf (backed by StackBlitz), the PWA Summit, Perf Now in Amsterdam, and React India. Anthony Campolo predicts deeper framework integrations from Netlify, while Ishan expects more case studies and social proof for recently launched technologies rather than brand-new feature announcements.
Chapters
00:00:00 - Introduction and Housekeeping
Scott Steinlage opens JavaScript Jam Live, welcoming listeners and co-hosts Anthony Campolo and Ishan Anand to the weekly Wednesday show. He highlights the strong listenership growth from the previous week's episode on Heroku, which jumped from 100 to over 900 listeners in just two days.
Ishan reminds the audience that past episodes are now cross-posted to YouTube and available at javascriptjam.com for long-term access. He sets up the two main topics for the day: the rise of Rust in the JavaScript ecosystem, prompted by a CircleCI report on TypeScript overtaking JavaScript and Azure's CTO recommending Rust, and a discussion of the upcoming fall conference season.
00:05:35 - Why JavaScript Developers Should Learn Rust
Ivan joins the stage and shares his background working across C, Node.js, and Rust. He makes the case that Rust is closer in thinking to JavaScript than other compiled languages and that JavaScript developers can become productive in Rust surprisingly quickly. He references the growing adoption of Rust in JS tooling like SWC, Deno, and esBuild as a practical reason for developers to gain at least a working understanding of the language.
Ishan draws an analogy to the old BASF commercial—developers may not write Rust directly, but the tools they depend on are increasingly built with it. Ivan explains that unlike C, Rust is a smaller, more approachable language where the compiler acts almost like a pair programmer, guiding developers through errors with clear, actionable messages rather than walls of cryptic output.
00:13:22 - The Learning Curve and Rust's Empathic Compiler
Ivan estimates a four-to-six-week intensive ramp-up for JavaScript developers to become reasonably productive in Rust. He highlights how Rust's compiler goes beyond simply flagging errors—it suggests solutions and points to the actual origin of mistakes rather than just where the program failed. Ishan surfaces a quote from Rust compiler maintainer Esteban Kuber about inventing "sufficiently empathetic" compilers rather than just smart ones.
The discussion turns to the high-confidence guarantee Rust provides: once the compiler accepts your code, incidental bugs like accidental state mutations or typos are largely eliminated. Ivan notes this has been a universal experience among developers he's worked with, and that no one has reported making more bugs after switching to Rust, even if the initial learning curve feels steep.
00:20:19 - Key Pitfalls for JavaScript Developers in Rust
Ivan identifies the two biggest hurdles for JavaScript developers learning Rust. First is immutability by default and the borrow checker's ownership model, which forces developers to be explicit about state changes. While initially frustrating, this constraint mirrors best practices around encapsulation and leads to safer code. Developers form muscle memory around these patterns over time as the borrow checker itself continues to improve with each Rust release.
The second challenge is learning to think in types and design programs with static types from the start, rather than relying on loose object patterns common in JavaScript. Unlike TypeScript, which offers escape hatches like any, Rust demands full type correctness. Ivan acknowledges that early Rust code from JavaScript developers often carries recognizable JS-style patterns that work but aren't optimal, and emphasizes that this is a natural part of the learning process.
00:28:31 - Rust Performance and Wrap-Up on Rust
Ishan asks about Rust's performance, and Ivan addresses both developer velocity and runtime speed. On the developer side, he says productivity is strong once past the initial hump. On the runtime side, Rust performs comparably to hand-optimized C or C++ code and dramatically outperforms JavaScript due to ahead-of-time compilation eliminating the overhead of JIT checks and type uncertainty.
Ivan closes the Rust discussion by noting that JavaScript was never chosen for raw performance but for developer ergonomics, and that Rust manages to be competitive on both fronts. Scott thanks Ivan for the conversation and delivers a mid-show break, encouraging audience participation and promoting the weekly newsletter at composability.dev.
00:37:45 - Fall Conference Season Preview
Anthony Campolo shares his recent trip to the Solana Hacker House in Vancouver and mentions plans to attend Jamstack Conf. Ishan returns after connectivity issues, and the group begins surveying the fall conference landscape. Scott shares a curated list of upcoming events including Next.js Conf, the GraphQL conference, and the Evans Data Developer Marketing Conference.
Anthony highlights ViteConf, an online conference backed by StackBlitz featuring Vite creator Evan Yu, who was also a guest on one of JavaScript Jam's earliest podcast episodes. The group discusses additional conferences including the PWA Summit, Cascadia JS, React India, Remix Conf, Reactathon, and Perf Now in Amsterdam, noting the diversity of topics and formats available this fall.
00:51:21 - Conference Predictions and Closing
Anthony predicts that Netlify will showcase deeper framework-specific integrations at Jamstack Conf, particularly around their improved Next.js support, and hopes to see highlights from the Jamstack Innovation Fund cohort. Ishan offers a complementary prediction that this year's conferences will focus more on case studies and social proof for recently launched features rather than brand-new announcements, since many technologies are still maturing past the early adopter phase.
Ishan also expresses curiosity about developments with Svelte under Vercel's umbrella. Scott closes the episode by recapping the conference list, reminding listeners to subscribe to the newsletter at composability.dev, and inviting everyone back for the next Wednesday session of JavaScript Jam Live at 12pm Pacific Time.
Transcript
00:00:00 - Scott Steinlage
Hello, welcome. Welcome to JavaScript Jam Live. It is Wednesday. It must be 12pm Pacific Standard Time, or shall we say Pacific Daylight Time? Yeah, let's see here. I'm gonna bring Anthony up. Invite. What's up, bro? Nifty. What up, dude? You can join us if you want to. I don't know. It's up to you. Hello. How are you doing, Anthony?
00:00:32 - Anthony Campolo
I'm doing good. I was in Vancouver last week. That was fun.
00:00:39 - Ishan Anand
Cool.
00:00:40 - Scott Steinlage
Well, we will definitely find out what that's all about. So welcome to JavaScript Jam Live. It is Wednesday, 12pm Pacific Daylight Time. This is when we do our thing. This is where we talk about everything JavaScript and web development related. Here's Ishan. I'm going to make him the co-host. There we go. Sent the invite. Yeah. Today we're going to be talking about some awesome stuff. If you haven't seen our newsletter, we will link it here shortly. But you can go and check that out once I pin it and tweet it and pin it. Yes, Ishan, I sent the co-host invite. I don't know the delay. I swear, it's so much fun. That's one of the best things about this, by the way. Last week's JavaScript Jam has really taken off. Like, two days ago it had 100 people who had listened to it, and now it's over 900. Pretty cool. So that's a lot for, like, two days for us at least. Not too bad. Things are going.
00:01:55 - Ishan Anand
There we go. I'm finally up here. You know, I think it cut out for me again when it switches you to speaker, but it sounds like you were talking about the traction on last week's episode. Yeah, that was, you know, I think this week will, you know, this is always going to be the best week. But last week was a really fascinating discussion on Heroku, so I highly encourage folks to tune into that. And if, you know, I think the Twitter Spaces disappear after, what, about 30 days? But if you're listening to this past that date, we are now cross-posting those onto YouTube. If you go to our YouTube space as well as if you just go to javascriptjam.com, we're posting them up there as well so you can see them in perpetuity there. It's another way you can access some of these great conversations we're having.
00:02:54 - Scott Steinlage
Absolutely. That is exciting. Today we're going to have Ivan speaking with us as well about some pretty cool things too. So I'll go ahead and invite him up here, just so I have him up here when we get rolling with that. But yeah, if you're joining us, like I said, this is everything about JavaScript and web development related, and we're about to really kick off today with some fun stuff. So, Ishan, what's up?
00:03:24 - Ishan Anand
Yeah. Hey, so I think, Scott, you said this earlier: welcome to JavaScript Jam Live. It is basically an open mic for anything web development or JavaScript related. So we always like it when it's audience-driven as much as possible. Feel free to raise your hand. I'm happy to bring almost anybody up to the stage to speak, change a topic, ask a question, or contribute. And then, as Scott mentioned, we usually send out in our newsletter just some topics for discussion for the week. So I had three topics up there to talk about, and the first one I'm going to tell you about so you can think about it, which is: it's fall, so that means conference season is really upon us. There's the Next.js Conference, there's the Jamstack Conference, both are coming up in October and November. So I'm really curious what conferences folks are looking forward to and what predictions we have for what to expect from them. So I'll let you kind of do that in the background as homework as we move to the other topic, which is why I invited Yvonne here, which is there was some news this week about other languages stealing JavaScript's crown.
00:04:44 - Ishan Anand
One of them, no surprise, was TypeScript. And we linked to that article that TypeScript is overtaking JavaScript, according to a CircleCI report. Then the other one was from Azure's CTO, basically saying that Rust should replace C and C++ in all apps going forward. Rust is gaining a lot of popularity in the JavaScript space as an implementation language for tooling we depend on in the development ecosystem. So a lot of our tools are now being implemented in Rust instead of being JavaScript-native, which we take for granted in our tooling. And so we're hearing a lot about Rust, and I invited one of my colleagues.
00:05:35 - Ivan/Yvonne
Hello.
00:05:35 - Ishan Anand
Who's had a lot of experience with Rust. So for a JavaScript audience, Yvonne, I just want to ask: how should JavaScript developers view Rust? Should they learn Rust? Why or why not? And how does it compare? Let's just...
00:05:58 - Ivan/Yvonne
So, okay, thanks, Ishan. So let me just give you a little bit of background. I come from strongly typed languages, so I did a lot of C for many, many, many years, and then I did Node.js for many, many, many years. And then, starting last year, I also did a significant project in Rust. Right. So it's sort of like I've been around on both sides of everything there, and I think that the answer is definitely yes. Right. I feel like, especially with tooling, seeing tooling in the JavaScript community starting to depend on Rust, you do want to have that access and understanding, at least, of the language on which you're depending there. I wouldn't make the same argument for C, considering Node and that it's written in C. I wouldn't make the same argument. It's a more complex language, C. There are many, many more foot guns in it, many decades of backward compatibility, including with C++, etc. But I would definitely say that Rust is a smaller language.
00:07:21 - Ivan/Yvonne
I think that it's closer in thinking to JavaScript than our alternatives out there, non-GC alternatives. And so definitely I would say that yes, if you have bandwidth, if you're curious about it, and you want to contribute to the tooling, then yes, definitely learn Rust.
00:07:42 - Scott Steinlage
Right.
00:07:43 - Ivan/Yvonne
I would recommend that.
00:07:45 - Ishan Anand
Yeah, maybe I'll give some proof points for the listener. SWC, which is used in JavaScript tooling, even I believe parts of Babel and webpack, and esBuild is written in Rust. Deno, which is talked about multiple times, is written in Rust. So you may not... It's kind of like I remember this old commercial in the '80s or '90s for this company, BASF, and it was like, "You don't know the products we create, but we make the products you use better." That's what it's like for JavaScript developers. You don't write in Rust, but everything you use actually has been made better by Rust. There's an article, I think it was from someone, it was actually the dev rel at Vercel, and he said the future of JavaScript infrastructure is Rust. It's clearly picking up traction. Why do you think Rust... Why do you think Rust has achieved this kind of penetration into JavaScript tooling? The advantages over C make sense, essentially, to me, but why didn't people just keep writing it in JavaScript? Why is Rust getting traction?
00:09:14 - Ivan/Yvonne
I feel like the gap is not that large, right? Like, when you consider a dynamic language and a statically typed language, usually there's a chasm there, right? There is a chasm there. I feel like even last year, I've worked with multiple people that have never written any code other than JavaScript, in any programming language except JavaScript, and we were able to make them quickly productive in Rust. I would struggle to think that it would be as easy even in other languages that are of the same sort of... Look, I don't want to oversell it either. It's definitely a compiled language, right? You definitely need to get your types, you definitely need to break some ways of thinking or adapt them. But at the same time, it does a lot of type inference and actually depends on that. When you look at it, the way it works is very close to... It feels much less bulky than other alternatives.
00:10:36 - Ivan/Yvonne
Right. And I would also say one of the great things about Rust is that the compiler is really... how would I say this? I saw this tweet from one of the people that maintain the Rust compiler, and they said, "We spent decades building smarter compilers," or something like that, "and we should have spent decades building more empathic compilers," in the sense of, like, hey, a human is using this. So all our optimizations are great, but if the human can't understand how to operate this tool of a compiler well, or it's much harder than it should be, well then that's an obstacle to actually writing good code, right? And I feel like the Rust compiler... I think that I've never seen a development language or compiler, however the tooling works, work more with the developer. When I write code in Rust, I literally have, on one side, in JavaScript the flow would be run Nodemon, run the unit tests, and then on the other side have Visual Studio, or whatever your editor is, open.
00:12:03 - Ivan/Yvonne
Then as you're writing, the tests are restarting, whatever it is that you are using, and then the test will show you, as you're working, what is breaking, what is not breaking, etc. And it is a very, very similar experience writing Rust, except that the tests are replaced, for the most part, not obviously entirely, but for the most part, with the compilation, because you rely on that compilation more than you would normally rely on unit tests. So that is one advantage. Another advantage I also feel is that unless you start dabbling into asynchronous programming in Rust, asynchronous in the sense of now you're launching threads and you're doing this and you're doing that, it is close to that single-threaded experience that you can just start with and that you have in JavaScript. So maybe that's also part of the attractiveness. It's kind of hard for me to... Because I have a lot of experience on both sides of it, it's kind of hard for me to really grasp what would be just for the JavaScript audience.
00:13:22 - Ivan/Yvonne
But I can tell you that we successfully... We literally were a team of, you know, a mix, but the only language that we all had under the belt was JavaScript. And we successfully started working very quickly and very successfully in Rust. People adapted to it. There is a learning curve, but they adapted to it quickly. So how...
00:13:48 - Ishan Anand
So yeah, for a JavaScript developer, and then I want to let people know, feel free to raise your hand and ask questions and jump in, and we'll bring you up to the stage. But how long does it take, from a pure JavaScript web development background, to feel like you can be a little better than dangerous with Rust? What type of learning curve?
00:14:10 - Ivan/Yvonne
So what I've seen is, I would say probably four to six weeks, right? And we're talking about intensive four to six weeks. But maybe the biggest thing, the one comment that struck me, is I remember a developer telling me they'd never thought about memory before. And one of the things that Rust does is that, for the most part, you really don't have to think about memory, right? It does guide you in that sense much more directly. It guides you in the correct manner immediately, rather than you learning... Remember the JavaScript: The Good Parts book? So you could literally write C: The Good Parts book, right? And I'm coming to C as the other language. You could extract and be like, all right, there's a much smaller language inside there which is much better and easier and safer to use, right?
00:15:12 - Ishan Anand
That's [unclear].
00:15:14 - Ivan/Yvonne
And Rust is like that. When I started reading and learning Rust, I felt that the lessons from C and other languages like that were taken to heart. It really tries to guide you in the safety-first direction. You sort of have to take the safety off, right? Anyways, but I would say that's four to six weeks, to answer your question. I would say folks start to adapt. I won't oversell it. It's a learning curve. There is a learning curve. But if you rely on the compiler, I found that that was the most useful thing for me, which is: don't just write code. See what the compiler is telling you as you are writing it, right? How it sort of guides you. The messages are good. The error messages are good. They usually point well to the place that actually failed, which is a huge problem in compiled languages. You declared something somewhere else and then now, many, many, many lines later, it...
00:16:32 - Ivan/Yvonne
Something else fails, right? And the community is also good. There's a lot of support out there. There are a lot of good references. There's stuff like Rust for JavaScript developers and things like that.
00:16:49 - Ishan Anand
So you've mentioned this a few times, like a more empathic compiler. And let's just... I want to underscore what you just described, which is commonly you'll get an error from either the compiler, or even worse, maybe a runtime error, and it's where the problem failed but not where the problem originated. And what you're describing is that Rust takes a really strong...
00:17:13 - Ivan/Yvonne
Sorry, dropped.
00:17:14 - Ishan Anand
Making the ergonomics so good that it tells you where you actually made the mistake rather than where the program got confused. Is that the right way to say it?
00:17:25 - Ivan/Yvonne
Yes. And not only does it point you to the mistake, it tries to guide you in the solution. It tries to sort of tell you. The biggest stumbling block in learning Rust and thinking around Rust is the ownership of the state, of the variables, when you're borrowing or not borrowing it. This whole thing, the borrow checker, is the thing that actually makes it so safe and allows you to reason more easily around the ownership of what you're changing, right? Which is a significant source of bugs, like changing state. This is why we have encapsulation and hiding state, because we don't want everybody to be changing state. But when you think about it even further, not only do you not want anybody to be changing state, you want change to be safe, even in a greater context of a larger program. Change...
00:18:36 - Ivan/Yvonne
That's what Rust tries to solve. Then, when you're making mistakes in Rust, you see the compiler, or actually the people that wrote the compiler, going out of their way to try to help you and guide you in the correct use, in what are the modules that you might be missing that are not included, and really going deeper than anything I've ever seen before. I remember, in a normal... If you ever worked with C++ templates, like, you make a mistake in a template, you are looking at 500 lines of error for a single comma that's missing somewhere, right? It's a very cumbersome, very hard thing to debug.
00:19:22 - Ishan Anand
Yeah. And I just want to. You're saying it's not just that the community does this, it's actually embedded in the tooling. The tooling goes out of its way.
00:19:29 - Ivan/Yvonne
The tooling, when it gives you the
00:19:31 - Ishan Anand
error messages and things, correct? Like, the
00:19:33 - Ivan/Yvonne
tooling itself, the basic tooling. So the developers, the compiler being part of the community, work on this very... It's a very important thing for them, which lowers the obstacles all the time, lowers the obstacles to entry into the Rust ecosystem and writing Rust. And it shows, right? It shows that they're thinking about humans using this tooling rather than just tooling existing there to translate something from X to Y. Right. I feel like that is one of the core community values there in the Rust community.
00:20:19 - Ishan Anand
So that, I think, is actually a good setup for my next question, which is going to be: what are the key pitfalls you've observed, or the key concepts that somebody coming from a JavaScript background should make sure they nail? Or where have you seen common gaps or hurdles in learning Rust if somebody's coming from a JavaScript background?
00:20:45 - Ivan/Yvonne
Right. I would guess one of the things is the mutability of state. By default, things in Rust are non-mutable. You don't just go and write stuff into different places. You have to explicitly want to change the state of something. And this sounds like a thing that raises obstacles, but it actually raises obstacles in the right place. It raises the obstacle of like, hey, think about it. You're making a change. Reading is easy, right? We know from highly concurrent systems that as long as you make everything read-only, these are very simple systems to scale. It's the writing of the state, the change of the state, the propagation of the state that's always tricky, right? Always tricky in distributed systems, multi-threaded systems, even in single-threaded systems where you sort of get lost. You lose the narrative, like, who changed what, right? If you're not careful about it, if you're not hiding state, etc. So it's very explicit in Rust, but again, the compiler will guide you, and it will tell you you're trying to change something. And then the next step after that is, once you've started changing something within a function, in the way Rust thinks about these things, you've borrowed something, and there can only be one writer at a time, right?
00:22:25 - Ivan/Yvonne
It can't be written by multiple writers. So then some of the methods that might be changing the state of what you borrowed may not be available to you. It will depend on the case, right? Or you can't do, for example, a search over a map or a set just willy-nilly. You have to sort of get it right. And I have to say, it is frustrating, right? But it's sort of like you form a muscle memory after a while. You form a muscle memory of like, you know how to do this, right? So the borrow checker, which is this part of the compiler that figures out whether it's correct for you to write something somewhere, you'll be able to satisfy it. And I have to also say that they make it smarter and smarter every time, right? As they are releasing new versions of Rust, it gets easier to write code.
00:23:32 - Ivan/Yvonne
The borrow checker also gets smarter. So that is one thing. And then the other thing, more on the language level, another thing that I would say, more on the design level of when you're writing a program, and this is harder, but there are a lot of patterns that you naturally use in JavaScript that you can still continue using. It's just that they are now less optimal. If you think about objects and properties, etc., is there a better way to state it than to put everything in a map of string to string? Then you need to start thinking about types and thinking about types in advance. It's a skill that you need to develop over time. But there's no helping there. You just need to do it. And then after a while it becomes more natural to think in types, right? And anybody that's worked with TypeScript as well, that becomes easier. But I would say that the change there is similar, except that there is no... In TypeScript you always have an escape hatch of, you know, JavaScripting it, right?
00:24:56 - Ivan/Yvonne
Like, in essence, right? Here there are no escape hatches, right? It's like you really have to get it right.
00:25:03 - Ishan Anand
But you are, you're up against the wall.
00:25:06 - Ivan/Yvonne
You're up against the wall. There's nothing there, right? But when I see programs written by JavaScript developers in Rust, if they're just coming to the language, you will see the JavaScript way of thinking and solving problems in there. And again, it's not incorrect. It's just suboptimal. But I feel like, again, humans before computers, right? Unless you're writing something that needs to be highly optimized, yeah, you're fine. You figure this out later in the next iteration or in the next program or whatever it is. But that probably is the second sort of leg of it. But it's not tied necessarily to Rust, but rather to thinking in types and solving things differently than you would have solved them in JavaScript, right?
00:26:08 - Ishan Anand
So I hadn't heard the quote you referenced earlier, but I think I found it from... I think it's Esteban Kuber or Cooper. He said, "We spent decades trying to invent a sufficiently smart compiler. We should have been inventing a sufficiently empathetic one." It's on his Twitter profile, and he also has on his Twitter profile, "There are no bad programmers, only insufficiently advanced compilers."
00:26:33 - Ivan/Yvonne
That is funny. Yeah. So yes, it stuck with me. It really did. It must be a couple of years since he tweeted that, right? And it stuck with me. It really did. I can tell you this: they really, really, really try hard to have good tooling, to improve tooling all the time. And one of the great things is everybody that has switched to Rust from JavaScript or from something else, everybody that I've talked to on our team or teams or whatever, everybody has said, all right, that first step, that learning curve, is high. When the compiler starts just complaining all the time, and you're like, why again? Why is it complaining again? But Rust, more than any other language that I've seen, by far any other language I've seen, once you have convinced the compiler that your code is correct, once the compiler is like, yeah, fine, I'll compile this for you, you're really pretty damn certain that it works as intended. I'm not saying that there are no bugs. Obviously the algorithmic bug remains, in the sense of...
00:27:56 - Ishan Anand
You...
00:27:56 - Ivan/Yvonne
You just wrote the program incorrectly. But those other bugs of typos, of hey, I didn't mean to write in two places in the same thing, or whatever it is, the sort of incidental bugs, let's call them like that, those really go away. And it's been universal. There's no one that has said, oh no, now I'm making more bugs than before. No one, literally, that I can tell you.
00:28:31 - Ishan Anand
So we're almost at the halfway point. I have one, and we'll switch to the JavaScript conferences for the second half of the session. But the last question I just want to ask is the one everybody always asks about any language: how's the performance? I know the answer, but I'll just throw that out there because I'm sure some people are thinking about it. How is Rust's performance?
00:28:54 - Ivan/Yvonne
Well, so I would say that there are two performances, right? One is the developer's performance. And I would say that developer performance is, again, once you're over the hump... Again, it's not hard to get over the hump, but it is a hump. But once you're over there, I feel like the developer performance, the velocity it gives you, is really great.
00:29:24 - Ishan Anand
How about... I meant...
00:29:25 - Ivan/Yvonne
I know, I know. You want runtime performance. It gets close to any compiled C or C++, hand-crafted, etc. Will there be places where it's faster than that? Yes. Places where it's slower? Yes. But for all intents and purposes, especially for anybody coming from JavaScript, it's going to be fast. There's no comparison, no matter how JITed it is, between something that's interpreted and something that's compiled, where the compiler can reason around the types at leisure rather than very late in the game of JITing something, right? And once you consider any JITed code, it has to have exceptions, like, hey, I compiled something. I can now think that this is always going to be a number or a string or this or that. But actually, because they cannot be certain of this, there always need to be checks of what is actually inside of everything. This goes away in a compiled language. You have a static type table. It's just like you knew it in advance.
00:30:46 - Ivan/Yvonne
The compiler had sufficient time, a lot of time, to compile it into the most optimal code that you wanted. And so, comparatively speaking, JavaScript to Rust, Rust is always going to win. I feel like that's a... But no one ever wrote programs in JavaScript because of the performance. It's more about human performance rather than compute performance, right? So I would say that on both of these fronts, I feel like Rust is... Again, obviously you have to think differently around some things, but I feel like it's close enough to JavaScript. And I feel like that's why you see, also in the community, people naturally tending to it as well. You try it and you're like, well, this is not that hard. Everybody always said that it was hard, but it's not that hard. And I feel like Rust has enabled that for the JavaScript...
00:31:53 - Ishan Anand
That's great. Thank you. Thank you a lot for giving us the lowdown on it. Scott, do you want to just give us our usual station break and then we can switch topics to JavaScript conferences? Sure.
00:32:05 - Scott Steinlage
Hey, thank you all so much for joining us so far today. It's been awesome. Thank you, Yvonne, for joining us and hopping up here on the stage and chit-chatting about Rust and all of its pros and cons. So really cool to hear that perspective. For those of you who are just joining us for the first time, or if you're listening to this on the recording, thank you so much. We appreciate you. And by the way, if you are new to this or you've been doing this for a long time, developing, that is, it doesn't matter. We want to hear from everybody. So feel free to request to come up, ask a question, or even just make a statement, your opinion, whatever it might be. We'd love to hear from you. In fact, that's where some of our best conversations have come from, just from the audience participating as well. So feel free to do that at any point in time.
00:33:08 - Ivan/Yvonne
Yeah.
00:33:09 - Scott Steinlage
So don't forget, this is done every Wednesday at 12:00pm Pacific Time. And if you haven't checked out our newsletter yet, which we've been doing three, four weeks in a row now, three weeks, I have linked it up there at the top. You can check that out there to discover what we're kind of talking about today. And for any future newsletters, if you want to get that in your inbox and not miss out on everything JavaScript and web dev related, then you would need to go to composability.dev and sign up there. Not just that, you will also get access to our summit that we had in June or July. It's going to be awesome. If you have access to that, you get a ton of value. That's what we're shooting for, creating value and thought leadership and helping everyone [unclear] together. I think Ishan has lost connection here. Hopefully he'll join us back here very shortly. Let's see. Hold on. There he is.
00:34:31 - Anthony Campolo
Awesome.
00:34:32 - Scott Steinlage
Invite. Co-host. All right, and as we're waiting for Ishan to come up here, just wanted to see if anybody had anything else they'd like to speak of or have a question about. There we go. He's up. Awesome. All right, well, you weren't gone too long. I was just finishing up, so that's great. All right, well, thank you all so much, and on to the next half...
00:35:00 - Ishan Anand
of what we have to offer here.
00:35:18 - Scott Steinlage
Hey, Ishan, are you there?
00:35:19 - Ishan Anand
Yeah, can you guys hear me now? We can.
00:35:21 - Scott Steinlage
Yes.
00:35:21 - Ishan Anand
Yeah, sounds like I'm having connectivity issues, so we'll knock on... looking for wood here. But yeah, thankfully, thanks for recovering. But if I drop out or I have connection issues or I start breaking up, let me know. You know, one thing I was realizing when I came back on again is the usability on the speaker-to-request screen. So you're like the exact wrong space on the screen to tell you that it's been accepted. You need to respond to it. You're gonna have to hit back again at the bottom of the screen.
00:36:11 - Ivan/Yvonne
So you were...
00:36:12 - Scott Steinlage
Yeah, yeah, you were a little bit choppy there. But I think what you were trying to say was that the notification is in the wrong spot. The UX of what they've designed could be better, especially when you're requesting to come up or being invited to come up or whatever. But man, we lost Ishan again.
00:36:42 - Ivan/Yvonne
Hold on.
00:36:45 - Scott Steinlage
See if he comes back.
00:36:53 - Ishan Anand
All right.
00:36:53 - Scott Steinlage
I sent him another invite there.
00:37:02 - Ivan/Yvonne
Okay.
00:37:10 - Scott Steinlage
Maybe it automatically kicked him into the audience just because his connection was so bad. All right. Yep, he's out. Okay. Oh, fun, fun. So, Anthony, why don't you tell me: why were you in Vancouver? What's up with that?
00:37:45 - Anthony Campolo
Yeah, it was for Solana Hacker House. So Solana is a blockchain, and they were building projects for a week. Actually, I had to go before the final day where they actually showed the project, so I didn't get to see any of them. But I got to just hang out and meet a bunch of people and get kind of plugged into that ecosystem.
00:38:08 - Scott Steinlage
That sounds like a fun time.
00:38:10 - Anthony Campolo
Yeah, it's cool.
00:38:15 - Scott Steinlage
Awesome. Well, glad to have you back. Glad to have you back here in the States.
00:38:20 - Anthony Campolo
Yeah, not for very long. I'll still be in the States, but I won't be in St. Louis very soon. I'll be spending a lot of time in the San Francisco area, most likely. We gotta talk about conferences, and I'll probably be at Jamstack Conf.
00:38:38 - Scott Steinlage
Oh, yes, of course. Yes. We're all looking forward to those conferences. It is like that time of year, right? I mean, there's just conferences everywhere right now. So yeah. Ishan, I did send you the co-host invite. I don't know if you got it or not. There we go.
00:39:09 - Ishan Anand
Yeah. Hey, guys. Sorry. Hey, you know, I'm on Wi-Fi. Make sure that I'm on my better headset for this. Make sure I've got good connectivity. It sounds like maybe I should just reset my phone so this doesn't happen. But yeah, it sounds like you guys already started talking about conferences, and Anthony was talking about the Jamstack Conference he'll be attending. And so that was the other topic that we had in the newsletter this week: what are the conferences people are looking forward to? Anthony, what's on your agenda besides Jamstack Conference this fall?
00:39:49 - Anthony Campolo
That's the only one right now. There's going to be a Redwood Summit, but that's not really a conference. It's like the team kind of getting together to just hack on stuff. So that'll be the other kind of big trip I'll be taking.
00:40:03 - Ishan Anand
Where is the Redwood Summit going to be held? Is it online or is it in person?
00:40:10 - Anthony Campolo
It'll be in the Bay Area. Yeah. I mean, it's not like we're advertising or anything like that. It's kind of just a chance for the core team to get together.
00:40:18 - Ishan Anand
Okay. And, you know, there's Next.js Conference, which is coming up. Those are, you know, I would think the two...
00:40:31 - Scott Steinlage
I actually created a list. I just pinned it in the space here. If you look at my tweet, there's a whole list of events that are before the end of the year. I didn't know if any of those seemed interesting or what people would be looking at, but...
00:40:50 - Ishan Anand
Yeah, that's actually a great list. So there's Next.js on that one. There's GraphQL Conference, which we've been part of in the past as well. There's also the Evans Data Developer Marketing Conference. Anthony, I don't know if you're familiar with Evans Data at all or you've attended any of their events in the past. I'd be curious.
00:41:16 - Anthony Campolo
I'm not, no. Tell me about it.
00:41:19 - Ishan Anand
So they're an organization focused on developer marketing. They've been around for a really long time, actually, and probably when you think back to the pre-JavaScript ecosystem, developer marketing, so more classic developer marketing. And they've often had people from lots of big, classic tech companies talk, and they have this conference once a year on developer marketing in the Bay Area. When is that one? Let's click through. I think that's in October. I'm clicking through to find out when it is, and it has the list of speakers.
00:42:07 - Ivan/Yvonne
Yeah.
00:42:07 - Anthony Campolo
Looks like the 25th and 26th.
00:42:10 - Ishan Anand
Yeah, that's what it looks like.
00:42:11 - Ivan/Yvonne
Okay.
00:42:12 - Ishan Anand
Yeah, so they've been doing this for years now. I've always meant to go but never managed to make it out there. So I'm not sure if you're familiar with them, but they're another interesting conference.
00:42:27 - Anthony Campolo
Yeah. I mentioned ViteConf is another one. I think that's going to be a virtual conf. But I'll be curious to see that one because StackBlitz, I think, is the one behind that, and it's going to bring together a ton of different frameworks.
00:42:44 - Ishan Anand
So it's called Vite Conference, like for Vite, the web tooling conference. Oh, brought to you by StackBlitz, ViteConf.
00:42:54 - Anthony Campolo
They hired one of the lead maintainers, I think. And so it's been like they've sort of been shepherding it, I guess, which is pretty cool, I think, because they were integrating all of these starters into StackBlitz that used Vite. So it kind of made sense that the two are very intertwined with each other now.
00:43:18 - Ishan Anand
Oh, very interesting. So I didn't realize that. And it looks like Evan Yu, the creator of Vite, is going to be there. And just a shout out: one of the first, I think it was the first, JavaScript Jam episodes way back when on the podcast, if you go to javascriptjam.com, was Evan Yu doing an early demo of Vite. So that's really interesting. And I see that he's one of the speakers there. That's an online conference, you said?
00:43:53 - Anthony Campolo
Yeah, I think so.
00:43:55 - Ishan Anand
They've got a great lineup. I don't know how I've missed this one. That's really cool. Let's see. October 11th to 12th. That's definitely something we should be checking out. Okay. What else is on people's lists? I know that the PWA Summit is coming up. That's another online conference, and I had actually, on an episode of JavaScript Jam, the podcast... Again, if you go to the website, the creators of the term PWA, progressive web app, were on. Let's see if I can find the episode number. Let's see if you go to our homepage. It should be right on there. There it is. Yeah, it's, you know, Alex Russell and his wife, Frances Berriman, who coined the term progressive web app, were on episode 12. And one of the things I asked them was about the results from PWA Summit of the previous year, and they showed some very impressive stats. It's tempting to think PWAs aren't hyped about or buzzed about, but when you look at the things that make up a PWA in terms of the usage of service workers and the usage of all the kind of PWA-like features, it's actually higher on an individual feature basis than you would look at.
00:45:30 - Ishan Anand
It's just, you know, in some sense, PWA has kind of blended into the woodwork, and you may not realize it. So definitely a conference worth checking out. Even if you think PWAs are no longer a thing, they're still actually pushing the web forward. And it may just be we're in a, I don't know, call it a PWA winter. But all the things that are ingredients in a PWA continue to progress. And I think what's going to end up happening one day is maybe we'll come back and realize, oh, this is the same thing as PWAs a few years ago, it's just under a new name, and now we've got more penetration for these technologies. Foremost among them is push notifications now being available on both iOS and Android. I think it'd be huge for that whole ecosystem, so that's going to be really valuable. But I'm curious again from the audience, what are some of the other conferences people are looking at that maybe aren't on our radar? Feel free to raise your hand. Anthony, were there any others that came up? The Vite conference is a good one.
00:46:36 - Anthony Campolo
Yeah, that's the only one that I can think of because I'm not really super plugged into the whole conference scene. I kind of came up during the pandemic era, so yeah, I was never one who was traveling much. And now that I'm working for a Web3 company, I travel to kind of a different set of events and conferences than these. But I find that they're good conversation starters, that usually something will be some talk and people will be like, oh, what was this talk about? And why'd they talk about this and all the other things? And so I enjoy them for that. I usually just kind of catch up after the fact.
00:47:13 - Scott Steinlage
Got it.
00:47:17 - Ishan Anand
Is there a conference that happened recently that you've been meaning to catch up on? I have one myself. I missed the CascadiaJS conference, and that's one I've been meaning to catch up on. Is there anything else that comes to mind as a developer conference that's still on your list or you thought was really good this year?
00:47:36 - Anthony Campolo
That's a good example because that's one where people are talking about Enhance after the fact. I mean, I think React India just happened, or that's about to happen. That's starting like right now. So that's usually a pretty big one.
00:47:56 - Ishan Anand
Oh, that wasn't on my radar either. So that'll be... I'm adding that to my list here. That's a good one. Do you have a sense... What would you say was the best conference this year if you were to pick one?
00:48:15 - Anthony Campolo
Oh, I don't know. I mean, I went to Remix Conf. That one was fun. But aside from that, like I said, I'm not really super plugged into conferences.
00:48:29 - Ishan Anand
Okay, I'll say Scott and I were at Remix Conference. I thought that was very interesting and really well done. I know, Scott, you were at RenderATL, which was really good. I did not attend in person, but I watched all of Reactathon. I thought that also had a lot of good talks and was really good. I think one of the ones you highlighted, Scott, in that list, React Advance, also looks potentially interesting. A lot of times it's hard to get a conference that's going deeper, and so that's what I'm curious and interested in looking more into. And then there's a conference happening this fall, Perf Now. As regular listeners know, I come from kind of a web performance background. There used to be a conference in the US called Perf Matters that was held every year. And once the pandemic happened, they held a virtual version, and they did an amazing job pivoting in one month because it was in March. It was basically when everything all of a sudden shut down. So they pivoted immediately to a virtual format. And I hope it didn't burn out the organizer, but I know they did a lot of work to make it work.
00:50:00 - Ishan Anand
It was a great conference, but it hasn't come back yet. But the European version of that conference, called Perf Now, is going on. I think it happened last year, and it's going to happen this year as well in Amsterdam in October. So that's one that I'll definitely be checking out, although I won't be able to go to Amsterdam to see it myself, and definitely recommend folks check it out. Another conference that's coming up is JSWorld. That is a conference I've actually participated in in the past, and they have a USA version happening in November. That's another one that I'm interested in following. And another one I've spoken at in the past, but I won't be this year, will be React New York. In fact, I think we might have actually already missed React New York. React Day New York is actually the title. That's the one that just happened. Yeah, that's another one I'd recommend folks check out. A lot of good content in that one. And then again, if there's anybody in the audience, feel free to raise your hand. But the one that we all seem to know is the Jamstack Conference and the Next.js Conference.
00:51:21 - Ishan Anand
Anthony, is there anything, or anybody else in the audience, do you want to make predictions on what you expect us to see at either conference this year?
00:51:32 - Anthony Campolo
Well, I'm hoping to see stuff about the Jamstack Innovation Fund. I think that was a pretty interesting thing to happen this year, where Netlify kind of funded a handful of different projects and created a cohort. So not sure if they'll highlight that at all at the conference, but that would be interesting.
00:51:52 - Ishan Anand
Okay. Anything from a feature or technology standpoint you're anticipating or looking forward to? I know in the past, for example, there was the rollout of edge functions and edge handlers at prior years of those conferences. Do you have a sense of what you'd expect for this year or what you're looking forward to or you want to hear about?
00:52:20 - Anthony Campolo
Deeper integrations with the current frameworks, because I know that they have a frameworks team now that's in charge of making sure that there's feature parity across the different frameworks. So I'd be curious to see if they've... They've been touting they have really good Next.js support supposedly now, and they've built in features just for that. I think building in specific things for the frameworks is probably what I would predict to see more of.
00:52:51 - Ishan Anand
Okay, that makes sense. I'll tell you what my expectation would be. The likely prediction is more... A lot of this stuff was new last year, and so I think we're going to see more case studies to create more social proof for these new technologies, and then more ecosystem integrations. It's kind of the... When you roll out a new feature, phase one is the rollout, phase two is the early adopters, and the late majority aren't going to adopt until somebody else blazes the trail. It's like the CTO of a company on a previous episode of JavaScript Jam said, "I'm not going to adopt a technology until I know four or five companies that have battle-tested it. I don't want to be the one running beta software." A lot of this stuff was new, so they're waiting to see how others do. And that's my next logical progression prediction: to populate that kind of material rather than any new features. That would be my expectation. The other thing I'm really curious about is just to see any new developments with what's happening with Svelte now that they're under that umbrella as well.
00:54:13 - Ishan Anand
So those were. Those are mine, so to speak. Okay. Well, it looks like we are close to the top of the hour. I have actually a very hard stop at, at the top of the hour. So unless there's anybody else who wants to jump in, Scott, I'll let you take us out.
00:54:42 - Scott Steinlage
Awesome. Thank you so much. Appreciate it. So it is conference time of year, obviously. We just listed off so many different ones, and a lot of them are happening around the same dates, and some of them on the same dates. So yeah, you can check out the list that I made and the couple that we mentioned that were not on the list as well. Maybe there's something that piques your interest and maybe you want to go to it. Anyway, lots of great conversation today. Thank you to everyone who was up here speaking and those [unclear]. And you can join us next week on Wednesday at 12pm Pacific Daylight Time, and we will be doing more awesome conversations about JavaScript and web development. Thank you so, so much. And don't forget, if you haven't checked out or subscribed to our newsletter, you don't want to miss out on all the wonderful things going on in this area. So go to composability.dev, register, sign up, and you can get our awesome newsletter every week. All right, y'all, thank you so much. We'll see you next time on JavaScript Jam Live. Peace.
00:56:12 - Anthony Campolo
Later.