Charles Max Wood (01:27.9)

Hey, welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapir.

 

Dan (01:43.451)

Hey from a hot and sunny Tel Aviv.

 

Charles Max Wood (01:46.985)

AJ O'Neil.

 

AJ (01:48.758)

Yo yo yo, it's Overcast.

 

Charles Max Wood (01:52.962)

Steve Edwards.

 

Steve (01:54.922)

Hello from a very crappy microphone today.

 

Charles Max Wood (01:58.764)

I'm Charles Max Wood from Top End Devs, and this week we have a special guest. We have him back. It's Lane Wagner. Lane, do you wanna introduce yourself, remind people who you are and why we like you, and then we can get going?

 

Lane (02:13.512)

Yeah, I'm not sure if everyone likes me, but I was here about a year ago. I'm the founder of boot.dev and the host of another podcast called Backend Banter. Excited to talk about JavaScript on the backend today.

 

Dan (02:26.724)

If I can pause us, sorry, I apologize, but I'll pause us for a second because Steve if you can mute While you're not speaking because it creates a lot of background noise. Thank you

 

Charles Max Wood (02:26.732)

Yeah, then y'all know who his favorite guest is.

 

Charles Max Wood (02:39.724)

Well, we all know who Lane's favorite guest was on that show. I'm just gonna, you know, anyway. But yeah, let's jump in.

 

Steve (02:46.418)

Hey, I'd like to say, Chuck, before, for those of us who are of my age, when I hear Lane Wagner, I think Better Off Dead and Lane Meyer, you know, one of the cult classics from the 80s. So, yes, so many good lines from that movie. If you ever need me to repeat some of the great one liners, let me know. But we'll let it go at that.

 

Charles Max Wood (02:57.883)

Such a good movie.

 

Lane (03:02.068)

John Cusack.

 

Charles Max Wood (03:08.221)

Steve, I want my two dollars. Anyway.

 

Steve (03:10.546)

Well, that's not him though. His better line is, I once built a bird house in Woodshop and it was condemned by the Fair Housing Committee, lines like that.

 

Charles Max Wood (03:22.112)

Oh, anyway, yeah, go watch the movie. It's definitely, we'll do a preemptive pick on that. So yeah, so we're jumping in. We're gonna be talking about whether or not JavaScript should be done on the backend, I think was kind of the, or just talk about JavaScript on the backend. It sounds like everybody has an opinion on this, which always makes it fun. But yeah, since you proposed the topic, Lane, why don't you go ahead and...

 

kind of set the stage for us.

 

Lane (03:53.948)

Yeah, absolutely. So I was writing an article a couple of weeks ago and I had to throw this spicy take in there. And I just thought of it when we talked about coming and doing this podcast again. JavaScript on the backend was almost by definition a mistake in the sense that JavaScript was written as essentially a domain specific language for browsers. And I think just by necessity or convenience, we've kind of adopted it.

 

on the back end. Now I have a bunch of kind of nuanced takes about like in 2023, should you actually do it? And I think the answer to that sometimes is probably yes. But it certainly is not a language that was written with the back end in mind.

 

Dan (04:38.472)

Yes, I agree.

 

Lane (04:41.021)

You're muted AJ.

 

Charles Max Wood (04:44.52)

Yeah, yeah, he's still muted.

 

Dan (04:45.479)

Yeah, AJ is at his best when he's muted.

 

AJ (04:50.126)

No, screw you. So Mike, I was going to drive there. Why would you even say that? Because a language, if a language is good, what about a language makes it quote unquote backend or front end that is that doesn't even compute for me. A language is defining logic. It's either a good language. It defines logic. Well, or it's a bad language. Doesn't define logic. Well,

 

Well, I mean, there's, you know, sliding scale, whatever, but, but there's no such thing as a backend language versus a front end language.

 

Dan (05:19.083)

Uh.

 

Charles Max Wood (05:26.092)

I guess you're, I want to chime in on this just a little bit because in a certain sense you're right and in a certain sense we don't talk about it that way. Right, because when we talk about JavaScript, you know, we're, yeah, we're talking about the language and we often conflate the engine with the language and the, you know, the constructs that kind of fall underneath it with the language, right? So yeah, the language is defining logic.

 

Dan (05:26.207)

Hmm

 

Charles Max Wood (05:51.704)

But realistically on the back end, right? We do have the eventing and some of the other things that come with the language that are part of the specification that the engine does for us that may or may not actually help us. And so it's, I don't know, it's a little bit of both, right? And I mean, we see Bun and Dino coming out, right? Because they want the engine to work differently and still follow the spec. And so, yeah. Well, they want it to be compatible with

 

Dan (06:16.444)

What's back?

 

Dan (06:21.972)

note.

 

Charles Max Wood (06:22.036)

whatever JavaScript or ECMAScript or Node defines, right? Yeah. Well, that's a different thing altogether, I think.

 

AJ (06:26.062)

TypeScript, Babelscript.

 

AJ (06:32.226)

Well, if you're throwing bun in there and, and Dino, then it's not because they, well, you know, that the idea with Dino was going to be TypeScript first. And the idea with bun is TypeScript first.

 

Dan (06:32.416)

Ah ah!

 

Charles Max Wood (06:43.167)

Okay.

 

Dan (06:43.279)

Yeah, but both of them, the idea, well, bun from the get-go was to be as compatible as possible with Node.js. And Dino is kind of being forced now to take a similar approach, even though initially they took a different one. But I would like just to point out that really prior to V8, then really JavaScript on the back end was

 

was problematic for performance reasons, if nothing else. People forget how bad JavaScript actually used to be on the back end. Although, now that I think of it, ASP, Microsoft's version of PHP, had JavaScript support from early on. So most people use VBScript in it, but it did support JavaScript from almost the very beginning. So people could be.

 

do JavaScript on the backend, like from the early 2000, maybe even late 90s, I need to check when ASP actually came out.

 

AJ (07:49.302)

So I think there was a time period when, yeah, yeah. I think there was a time period when JavaScript was used as an alternative to bash. It was, it was better than bash for getting cross-platform scripts to run. And that's back when we had Rhino and windows scripting host. And those were not asynchronous. They did not implement the asynchronous part of the spec. So, and, and they also did not implement any sort of scope. So you define something. I mean, it was, it was very much.

 

Charles Max Wood (07:50.296)

Well, they used to have Rhino as well that ran on the JVM.

 

AJ (08:17.73)

kind of like the PHP nightmare experience where you define something in one file. And then literally 50 files later, you reference a variable where the flip did this come from? You don't know. It didn't, it didn't, a lot of, a lot of the way that was written, didn't look like JavaScript. I didn't know that I was dealing with JavaScript when I was dealing with Rhino for a while and, and until finally I realized, Oh, this isn't just similar syntax, this is a different runtime that just has lots of weird features.

 

Dan (08:42.839)

I also think that you're absolutely correct, AJ, in saying that if a language is complete, let's say not just a very domain-specific language, but in fact a general purpose language, and obviously it can be used for whatever, and that includes the backend. But realistically, JavaScript gained certain features that made it more appropriate for

 

Charles Max Wood (08:54.965)

Mm-hmm.

 

Dan (09:11.403)

web style development. And conversely, these features were missing before they were added. So back in the day, it was potentially less pleasant. Let's put it this way as a back end language.

 

AJ (09:24.97)

I want to hear lane. What are your thoughts on that? Like what, why are you saying this? Why, why are you making this take?

 

Lane (09:30.576)

Yeah. So like zoom way out and get really nitpicky about terminologies and you know, I'm definitely conflating terms here and I will continue to do so. But the language being Turing complete, basically by definition, do whatever the hell you want, right, it's JavaScript, Go, Rust, you can do anything with these languages. But certain design decisions are made when you're creating a programming language. And it goes,

 

beyond just the language, right? There's tooling, there's the runtime. In some cases, there's a compiler. And it's really that entire ecosystem that I'm talking about when I say, this language was built for browsers and was designed for browsers, or at least for the web. Whereas other programming languages kind of have other things in mind. Like a good example is, I would argue that Go very specifically from the beginning had a lot of stuff for like backend and service-based.

 

you know, web programming baked into the language, or at least, baked into the tooling and the standard library. And JavaScript had the same thing, just with a different domain in mind.

 

AJ (10:42.086)

So I'll, I'll drink to that. Right? Yeah. Go is by far the best engineered language for, uh, web services. Like bar none, there's no competition in the space. There's nothing else that, that can compare. There's other languages that can get as good performance. If you're smart enough to tweak all the settings, but out of the box, there is nothing better than go, uh, please someone, you know, change my mind, but.

 

Charles Max Wood (11:09.696)

Welcome to Go Lovers Jabber.

 

AJ (11:12.642)

But if you take a look at the other languages, Pearl, PHP, Python, Ruby, when went to Ryan doll, he wrote his HTTP parser for Ruby and was, was planning to use it with Ruby event machine and Ruby sucked. And so he adapted it to Chrome.

 

And it was great. Now, when I say sucked along the, along the domain, hmm, V8, sorry. Yeah. Sorry. I, I misspoke, but, and, and when I say sucked, what I mean is the runtime characteristics of Ruby were terrible in that trying to shoehorn in, uh, multi-threaded requests was too challenging and the benefits weren't really there and the.

 

Dan (11:43.839)

No, it's like adapted to V8, to be precise, V8.

 

AJ (12:10.306)

the interpretation of the language wasn't fast enough. So Ruby as a language to learn is probably a better language to learn than Python. But as a language to use might even be a worse language to use than Python. Whereas node was able to do multi-threaded requests and was able to take advantage of the advanced JIT of JavaScript. So I guess you could say, well, what if Ruby had a better JIT? What if all the money?

 

that had been poured into V8 had been poured into Ruby, maybe Ruby could have been as good, but the primitives weren't really there.

 

Charles Max Wood (12:46.168)

I am going to not pick bones with half of what you said.

 

AJ (12:51.019)

I did.

 

Charles Max Wood (12:53.036)

No, because we're talking about JavaScript. We're not talking about whether or not Ruby was, is.

 

AJ (12:57.034)

We're talking about was, was JS on the back end of mistake. And we have to have something else for comparison, right? We have to have some other thing to say, okay, with JavaScript is bad. Well, what's better at the time? Go had just come out and go was obviously superior, but it, the hype train was on jQuery, but, but anyway, it responds.

 

Charles Max Wood (13:02.368)

Yeah, fair.

 

Charles Max Wood (13:18.38)

No, it's, you know, I mean, there were definitely performance issues. Node had a lot of the same restrictions as far as like threading and, you know, the way that it managed specific things. Yeah, some of those things were easier in JavaScript and some of those things were not. But yeah, I mean, ultimately what it came down to was that the way that people thought about specific things, especially in the eventing space, that just wasn't something that

 

We did a whole lot of it in Ruby, and JavaScript did that more natively, and so people adopted it. But, you know, anyway.

 

AJ (13:56.31)

Yeah, the very thing that allows it to respond to click handlers is the very thing that made it able to run on the server performantly.

 

Lane (14:05.692)

I think there's a lot of truth to that. Like when I compare Go servers, Python servers, and JavaScript servers, which is something I do very often on boot dev for my students, there's some clear performance gains that you get with a node server over a Python server. And like AJ said, the whole idea of like single threaded async can actually be extremely performant. And at first this was actually something that was kind of hard for me to grok like years ago when I was learning about this. I mean, why would single threaded ever

 

ever be faster, but you do have like overhead, right? When you actually spawn new threads and JavaScript can do away with that whole problem in a very kind of simple way because like it's almost coincidental. It's like it's stumbled into this design pattern because it was built for UIs.

 

Dan (14:57.275)

Yeah, I would like to add that it does help when Google, Apple, the open source community and Microsoft all compete to see who can build the fastest engine, which is something that no other scripting language had going for it. So some other scripting language might be...

 

Charles Max Wood (15:11.309)

Mm-hmm.

 

Dan (15:21.235)

have better performance because they were designed from the get-go for better performance, but just taking an existing language and trying to squeeze all the performance you can get out of it. I don't think any other language had this benefit to the extent that JavaScript has or had. So that's one thing. Another thing that I would like to point out really is I think...

 

that when talking about JavaScript on the backend, there are really two types of backend. And from my perspective, a distinction needs to be made. So there's like node as a general purpose backend, but then there's something like Next.js or Remix or all the other meta frameworks that are coming out these days, which are

 

AJ (15:58.492)

Mmm.

 

Dan (16:18.455)

specifically designed for a particular, I won't say use case, I would more say application development model for web applications.

 

AJ (16:30.702)

And I thought you were going to talk about things you need, like a database or mode balancing or things that are important.

 

Charles Max Wood (16:39.296)

Well, no, I agree with Dan to the degree that, yeah, I mean, how you use it is ultimately what your experience is, right? And so...

 

Dan (16:39.464)

I- Yeah

 

Charles Max Wood (16:55.248)

you know, if you're using it as a general purpose language, or you're gonna, you know, stack sales or express or something on top of it, right? That is different from, you know, some of these other ones that grew out of sort of a front end focused deal, but have a backend, a large backend component to them like Next.js. And they are gonna perform differently and, you know, anyway.

 

Lane (17:22.62)

I tend to agree there's those two classifications. There's also the third one that I think is more prominent if you're kind of coming from like the deep backend world, which is like, you've got a backend that serves a frontend and then you have backends that serve other backends, right? Like you're just building a service that's consumed by other services or maybe just doing data processing and like an ETL pipeline. So things that don't even have like a nice REST API or GraphQL API that like...

 

a browser would consume. And in those cases, I would argue, JavaScript makes even less sense because now you're not even necessarily talking about your front-end developers having to interface with the backend at all.

 

Dan (18:04.163)

So there's this concept of BFF, you know, back end for front end, where the front end developers built a certain part of the back end, which is usually actually a sort of a middleware, where you like instead of invoking various back end services or microservices directly from the front end.

 

you invoke them from a common backend that is like a facade for all of them and aggregates data from various separate services into like a single API response or whatever. So instead of making, let's say lots of back and forth trips to various separate services, you make a single call to this kind of a backend, which then makes, you know, calls to specific

 

services gets the results and, you know, mashes it all up together and then sends it directly to the front end. Now, does that mean my backend is JavaScript? I mean, we kind of use this approach at Next Insurance where I work. So, front end developers are in charge of this sort of a backend middleware implemented either in some cases in Next.js.

 

some other cases in as Nest JS and but the actual you know back end back end that part which talks to databases and you know these sort of things that's actually implemented in our case using Kotlin on top of the JVM.

 

Lane (19:51.68)

I've worked in this kind of an architecture before, and I think there can be benefits. I've also seen it done very poorly though. So like in the past, I've called it like an API gateway, right? You have like your front end application, you have like some gateway service, a backend for the front end, right? That's written in probably node. And then like one person or one team is responsible for both sides of that, right? So you kind of get some efficiencies there in the sense that the same people are working on both sides of that API or that interaction.

 

But where I've seen it go wrong is when the other services are all also just kind of REST APIs. And so now you just have like this API dependency explosion with no clear benefit of like why that's useful. Where I've seen it done well is like, you still have that same architecture, but there's very clear reasons as to why you're calling back to some other backend service, right? Like maybe the service back there is written in like a Go or Rust for performance reasons because it's doing data processing.

 

Or maybe you get type safety on the, because you're doing gRPC between those services or something like that. So whenever I've worked in that sort of situation, I feel like that has to be a clear reason for that sort of API explosion, so to speak.

 

Dan (21:03.987)

That's an interesting-

 

AJ (21:04.19)

What if it's because it's the developer's pet language?

 

Dan (21:09.766)

Which language?

 

AJ (21:11.906)

whichever one they chose that wasn't.

 

Charles Max Wood (21:13.988)

Well, I think there's a case for that, right? I mean, to a certain extent, if the performance characteristics or the architecture behind it don't matter as much, and I can get a ton more done in my language of choice, right, it's only when you have an actual problem that the actual language or engine solves a lot of times, that's where it really is gonna count.

 

Dan (21:29.235)

Yeah...

 

Dan (21:37.083)

Yeah, but realistically, I mean, who's really doing extreme computationally intensive stuff even on their backend these days? I mean, really, are you computing like pi to the billionth digit? I mean, we are making database calls, getting the data, aggregate, you know, massaging it a bit and then passing it on.

 

I'm seeing most services run at fractions of a percent of the CPU in most cases. So.

 

Lane (22:15.024)

It depends so much, like a ton of applications fall into that bucket, right? Like you have a CRUD application, your API layer effectively does nothing. Like maybe handle, like it maybe parses a JWT or handles a cookie or something. But there is a lot, and most of my career actually has been in working in those computationally expensive services. It's not necessarily computing pie to the thousands digit, but it's like, you know, we're processing.

 

thousands of tweets per second, and we're looking for keywords or something like that. It's, you know, we're processing frames of video. So it's very domain specific, but I would argue there is a large, especially in like B2B SaaS, there's often a large data component if you're building something useful.

 

Dan (22:50.927)

Yeah.

 

Charles Max Wood (22:58.84)

So can I just ask this? Cause we're kind of talking about all these use cases. And I think we're kind of flirting with the, it depends answer as far as whether or not JavaScript is a good backend option, right? But my question is, is how, how does this lead us to making some kind of conclusion, whether it's this case is great, this case it's not, or, you know, overall, hey, you ought to be using this and not that. I guess that's where I'm trying to.

 

Dan (23:09.378)

It's always the case.

 

AJ (23:12.866)

The answer is yes, it is.

 

Charles Max Wood (23:28.492)

Figure out where we're headed.

 

Dan (23:29.827)

My case would be, I would tackle a very particular use case. If you're doing sophisticated JavaScript programming for the front end, say you're building some sort of an SBA, then there's a strong case to be made that you should have JavaScript on your back end as well.

 

not necessarily for the entire backend, but for the direct backend that you access from the frontend. For stuff like SSR or SSG, you know, what used to be called isomorphic JavaScript. Basically the fact that you don't want to do your HTML templating twice in two distinct programming languages. Now you may address this by...

 

using some sort of a mechanism that generates the JavaScript for you. So you do your, all your templating using some other language rather than JavaScript. And that's a valid solution. But if you're doing your templating using JavaScript, let's say using JSX or using view, then there's a strong case to be made that you want to do.

 

templating for JavaScript, for HTML on the backend using JavaScript as well, just so that you don't need to maintain two different code bases for the same functionality.

 

Charles Max Wood (25:03.908)

Okay, I have two bones to pick. Or I agree with you on like SSR, SSG, you know, some of that stuff, yeah, it makes sense. The tools are there, they do the thing, whatever. But a lot of times when I talk to people about isomorphic or, you know, sharing logic between the front and the back, a lot of times the concerns are different enough to where they try and make the code shareable between the front and the back and it's just not realistic.

 

And so to the extent that you have similar concerns and similar engines and similar frameworks, you can do that. But in a lot of cases, I just don't see it. I really just haven't seen the use case where it's like, hey, my logic for my data entities or data models, they're just not the same because the one's concerned with display and the other one's concerned with logic.

 

Dan (25:56.319)

Oh, yeah, for sure. Then like I said, use the JavaScript as a thin layer and move a lot of that backend logic to microservices that you or services that you access from that backend. So the backend could potentially have relatively little in the way of business logic per se.

 

Charles Max Wood (26:09.097)

Okay.

 

Dan (26:25.759)

have like if you're going to be generating the UI for let's say a panel or something on both the server and potentially the client, you don't want to...

 

Charles Max Wood (26:34.292)

Yeah, that seems like an obvious case, yeah.

 

Lane (26:38.652)

Yeah, don't do that.

 

AJ (26:39.866)

I think you got to get back into the backend mentality though, just the general programming mentality, not thinking about what you're rendering, but what you're doing. Right. So right now I'm working on a cryptocurrency wallet for Dash and the code is the same for the front end, the backend and, uh, fingers crossed we get to use it on mobile as well. It's it's cryptographic algorithms with rep web crypto. It's logic about.

 

how to map an ID to an amount, how to call, whether you're on the front end or the back end, you still have to call API's in order to get balance updates for specific addresses, not to go too much any further into the technical details of it. But the code, the core code that's valuable, the only thing that needs to be different is presentation layer, which, you know, that's a big, huge thing, right?

 

Cause on the presentation layer on the backend means the API to the front end and presentation on layer on the front end means what the user sees. And presentation on mobile is the, I guess, the bridge between the JavaScript code and the native code. But then, and then the storage engine. So on the backend, it's Postgres on the front end, it's index DB on a mobile, it's a core storage. Right. But, but

 

The bulk of what it needs to do is the same in all three places. It's the same logic. So, I mean, I get that a lot of people are just doing, uh, you know, you just, you just render a thing, but

 

Dan (28:20.027)

I'm not seeing people doing, most people doing a lot of data, persistent data storage on the front end, I have to say. So indexedDB is all nice and good, but most web developers aren't using it.

 

AJ (28:36.362)

No, I don't disagree with that. I think that's one of the reasons things are, we're in the state that we're in. People don't know, one of the hardest things in computer science, cache invalidation. People don't use caches because they don't know how to invalidate.

 

Dan (28:46.904)

Yeah, I-

 

Dan (28:51.431)

I do have to shout out some of the comments being made on our chat by X Wind Wolf. Yeah. So he made a couple of really interesting points. Uh, first of all, about the fact that basically calling out some stability issues with JavaScript and, and node in particular as the backend system. And it's something, something that I've definitely heard echoed from various backend developers who kind of poo on that platform.

 

Charles Max Wood (28:55.436)

Yeah, there's some good ones.

 

Dan (29:17.623)

Like the fact that if you're going to be using NPM, you're going to be bringing a ton of stuff, like from who knows where into your running image, which is both a security potentially issue and also like a size or space potentially issue, like how big your image is going to get. Also, I basically just heard

 

things from back-end developers talking about the lack of maturity of node, let's say, as a full-fledged back-end system for large-scale things. Like, people saying that JVM and its garbage collector have been optimized for the back-end extensively over the past decade or so and have tooling from here to whatever for...

 

profiling and identifying issues and tweaking it and no Isn't there Now I don't consider myself enough of an expert to To say whether this is really the case or not. I'm just saying that I've heard it from various back-end developers

 

Lane (30:36.104)

Well, we can't trust them. They're writing Java.

 

Dan (30:40.447)

hahahaha

 

Lane (30:44.02)

But for the sake of argument, let's just assume it's true. No, I mean, the way I look at it, to kind of go back a little bit to the original question of, when is JavaScript good? When is it not? That use case of, oh, well, JavaScript's not mature enough. I can't profile my JavaScript code as well as I can profile my Java code or my Go code or whatever. I don't know.

 

Charles Max Wood (30:49.337)

Ha ha.

 

Lane (31:10.088)

I haven't tried to do too much memory and CPU profiling in JavaScript because anytime I've needed better memory or computing performance, I've just written that service in Go and called it. This is where I draw the line in a lot of cases. If I'm having computational bottlenecks in JavaScript on the backend, can I just write a microservice in Go or in one of these languages that is easier to...

 

to do high performance compute in. Because JavaScript can do high performance stuff, but it's like, I would argue the best use case is high performance IO. It's really good at handling lots of requests, making lots of database requests at the same time and handling it all in one thread. It's not necessarily good at parsing a ton of JavaScript and doing string manipulation as quickly as you might do in other languages.

 

Dan (32:02.027)

Frame manipulation probably, it would probably do fairly well, where I would say that it might be a laggard, let's say would be like intensive computational stuff, like a lot of sophisticated image processing. So anything that requires sophisticated data structures, stuff like that. JavaScript is probably not the ideal.

 

Charles Max Wood (32:17.348)

like image processing or something.

 

Dan (32:31.659)

programming language for that. And if somebody says anything that requires integers, that's actually not a hundred percent true. I have to point this out. So there's an interesting aspect about the job about JavaScript engines. And it's that they are able to identify hot code and then they optimize it if they can. And if you're type consistent,

 

Lane (32:35.411)

Yeah.

 

Dan (32:58.979)

throughout your code, they can actually do a lot of magic in that regard. Identify that the particular variable that's supposed to hold a number actually always contains integers and then generate assembly code that specifically works with integers.

 

AJ (33:15.234)

Well, it's not even necessarily magic. It's just if you don't do stupid. I mean, like.

 

Dan (33:20.783)

Yeah, no, I mean, the engines are magic. You need to just not be stupid. Yeah. Yes. Yes, so, but yeah, but just to finish, the point that I was trying to make is that backend services actually have an advantage here over frontend stuff because they tend to be longer running, which gives the optimizer much more time and chance to like...

 

Charles Max Wood (33:23.748)

but sometimes it makes it easy to do stupid. But that's gotten better. That's gotten better, but yes.

 

AJ (33:27.506)

Yes, yes. Yeah, yeah, I think that that's.

 

Dan (33:50.563)

like gork the code, understand it, identify the hotspots and optimize them. In fact, one of the problems with tooling, a lot of tooling has been written in JavaScript and it is now being rewritten in Rust or Zig or whatever, is that most tooling isn't that long running. You run it, it does its work, supposed to do its work for a few seconds and then the process is done.

 

Charles Max Wood (34:04.961)

Mm-hmm.

 

You're talking about like turbo repo and stuff, right?

 

Dan (34:19.611)

It never actually gets a chance to optimize anything. And a long running note server on the other hand, has a very long time in which it can actually like, you know, leverage the built in optimizer in the JavaScript engine.

 

Dan (34:38.323)

So there is that. So your node server might not be as slow as you think that JavaScript might be, is my point.

 

AJ (34:47.518)

And also you don't have to write crap JavaScript. You can write good JavaScript. If you copy and paste from, you know, somebody who's built up 20,000 followers on Twitter with hot takes and dumb questions and you copy from their tutorial, then maybe, maybe not. That was, no, you know what I'm talking about, Twitter culture right now with all these fake devs. Anyway, but you can write good.

 

Dan (34:52.691)

Yeah, you can.

 

Charles Max Wood (35:04.172)

Hey! Oh, sorry.

 

Charles Max Wood (35:10.143)

I do.

 

AJ (35:15.746)

good JavaScript and, and like, like Dan was saying that the, the optimizer can be pretty good. So in the whole dependency problem, shout out to socket security. You know, you don't, you don't have to use tons of dependencies, but you can also that was more tangential of referring to something we're talking about several minutes ago, but you know, you can use something like socket security. So you don't have to worry about the, the supply chain. I mean, like you're in control of that. You don't have to use bad code, but

 

I am interested because my understanding is that the JavaScript is actually pretty fast and that if you're looking at the difference between go and node, I don't is go really always a clear win in terms of performance? I mean, by what margin?

 

Dan (36:05.027)

I think it's more a question of cost, by the way, rather than actual scalability. I mean, you can always scale out. It's just a question of how much is it going to cost you. And by the way, I tend to always go back to your own statements, AJ, about the fact that for most SaaS things out there, like having

 

A single node server is probably will scale you enough for whatever size you are likely to grow your business. You'll probably want to for redundancy, but in terms of...

 

AJ (36:40.354)

Well, you need, you need to, you need, you need to not just for redundancy, but to catch bugs because so many people, like, this is a problem that in go your main. Execution runs on multiple threads in JavaScript. It is multi-threaded. It, it, there are multiple threads going, but the main execution thread, when the event loop hands back to that is only running in, in a, in a single thread, but you still.

 

You still have issues where once you run it on two servers, you have the same problems that you would, you know, that you'd have in something like go right off the bat, because whenever something's running in two processes and you have two copies of memory, that memory gets out of sync. And that is something where I think that nobody should be running node on a single server, especially not in development. It's so crazy that our, our dev setups run on local hosts with a single node when that's like, you need to catch that crap early on.

 

Lane (37:26.268)

Yeah.

 

Charles Max Wood (37:39.724)

Now, I want to point out something important that Dan pointed out was that we keep falling back to performance. And a lot of times the concern is something else, right? It's not necessarily the performance. And so, yeah, I kind of want to, we did kind of push on supply chain and security, which incidentally, if you have a package manager for any language, that's a concern, right? But then it's down to the community and what's getting put in it.

 

put in there and why and what you kind of default reach out to solve problems in your app, you know, as a dependency and things like that. But but yeah, I just wanted to call that out because we've talked a lot about the performance characteristics, but that's not always the concern.

 

Dan (38:25.543)

Yeah, actually what I'm hearing from backend developers who choose other programming languages rather than JavaScript is not so much performance things. Rather, it's the fact that they want to be using type-safe languages. Now, sure, TypeScript exists and, you know, it... Yeah. So...

 

Lane (38:26.098)

So.

 

Charles Max Wood (38:47.244)

I'm hearing that a lot more often, the type safety.

 

AJ (38:50.562)

Types are amazing. Don't code without them.

 

Dan (38:53.335)

Yeah, so TypeScript exists, but the thing about TypeScript, it's types retrofitted on top of JavaScript. So there is this really big constraint that you want to support using types for all the, as many of the JavaScriptisms that we like to do, some of them really cool,

 

really difficult to express as in type safe ways. Yeah.

 

Lane (39:30.119)

So.

 

AJ (39:30.158)

I think that this is a huge problem in the JavaScript community is wanting to exploit every bug of the language, every mishap of the language, the whole idea, the whole, we can, we can use simple types, right? And JavaScript, you got unsigned and signed in 32. You've now got in 64 as bit arrays, as well as arbitrary size integers with big end, you know, like you've got

 

If you just say once of ours, a string, it's always a string. Once of ours, an N32, it's always an N32. If you keep with those things, again, the TypeScript checker is great for helping you make sure that you don't make mistakes there. But I think TypeScript itself, it's off the deep end. It's inheritance, polymorphism, generics. It's stuff that doesn't make sense to try to implement in JavaScript. Cause JavaScript's already a dynamic language in the first place.

 

Charles Max Wood (40:28.396)

Lane looks like he wants to chime in. Yeah, there you go. Ha ha.

 

Lane (40:28.532)

So there's, yeah, I gotta get in here. So there's, yeah, we said something earlier, we were talking about like, well, if we just don't do dumb things. And I think that's like the worst assumption we could ever make ever in programming, because I mean, I do dumb things all the time. And I feel like the best engineers are really just engineering better guardrails to stop themselves from doing dumb things. So, you know.

 

Dan (40:34.299)

You're the guest! Hahaha!

 

Lane (40:55.736)

I agree with AJ, we can write better JavaScript code. And I think to sum up a better JavaScript code in my mind is like, let's pretend 90% of the stuff in JavaScript doesn't exist and we'll just like do this 10% of it. And even better if we can like write linting rules that like will stop us from doing the really, really dumb things. Yeah, so the nice thing about Go.

 

AJ (41:05.547)

Yes.

 

AJ (41:14.527)

Yes.

 

Dan (41:15.719)

Which dumb thing, for example, which dumb thing for, I have to push back on that a bit because I'm not exactly in this camp, AJ knows this. Can you give a concrete example of a dumb thing in the JavaScript language that you explicitly avoid?

 

Lane (41:33.712)

Yeah, so like you can create a variable that is the string five and then later assign into it the number five And like why would you do that?

 

Dan (41:40.391)

Yeah, implicit. Yeah. Which is why I use always. I know AJ hates that because it's a misnomer, but that's why I strive to always use const the const keyword rather than the const concept. Um, but yeah, obviously like, you know, implicit type conversions in JavaScript are a problem, but you know, they're really, nobody really programs that for that anymore. Please set I see.

 

Lane (41:53.269)

Agreed.

 

Dan (42:10.353)

Uhhhhhh

 

Lane (42:11.156)

VAR in general, right? Like just using VAR, I would argue, is probably a mistake these days. Like you should probably use letter const, but like you can still use VAR, right? So there's nothing stopping you from doing the things you probably shouldn't do.

 

Dan (42:20.555)

Oh, yeah. One thing about JavaScript, the language, as opposed to other programming language is that once something has been put in, it can never be taken out.

 

Charles Max Wood (42:33.465)

That's the best and worst part, right? Is that you know that it'll consistently work, but yeah.

 

Lane (42:41.032)

Well, it will consistently do something. It might not work in the sense that your user thinks it's going to work.

 

Charles Max Wood (42:43.292)

Right. Yeah, right. And it has the constraint of if it's implemented poorly, that it will always have right that behavior.

 

AJ (42:46.902)

Well...

 

AJ (42:56.234)

Use strict took things out of the language and, and the optimizers found ways to get that down to the function level so that if you had a strict function, it could be optimized. But if your program in general was not strict, then the parts of it that weren't strict wouldn't get optimized. And I think, I think we can do the same thing. We could have a use types where when you use types, you're not allowed to change the type of something. Or you strong.

 

Dan (43:13.857)

Yeah, that's it.

 

Dan (43:24.383)

Perhaps, but effectively TypeScript has subsumed that role. People effectively get that these days by declaring a variable as having a particular type using TypeScript. So the need to implement this in JavaScript is reduced. Also there's the obvious issue with JavaScript if you did implement something like that, and that was kind of the whole...

 

That's the ongoing debate in TC39 about the type annotations proposal. Gil Tayar, by the way, who was a guest here on JS Jabber, speaks about it at length. There was an entire debate about whether or not this should also be enforced at runtime. And there are valid arguments going either way. But I think we're kind of derailing.

 

the conversation. The bottom line is back end developers want type safety. Back end developers don't like JavaScript because it does not have type safety. And they...

 

AJ (44:34.582)

The tools don't have type safety. Cause C doesn't have type safety, right? Type safety is in the tooling.

 

Dan (44:37.78)

What do you mean?

 

Well, who's using C on the back? Yeah, who's using C on the back end these days?

 

AJ (44:46.13)

Okay, I, yes, I know, I agree with you. If it were enforced by the runtime, that would be great. But we type types are not a runtime thing. They are a tool time thing because whatever code ships is the code that runs regardless of whether the code that ships is type safe or not. And it's up to, it's up to the things in between when you write the code and the code is processed by tools to check for types.

 

Charles Max Wood (44:47.482)

Ha ha ha!

 

Dan (44:58.972)

Yes, but most-

 

Dan (45:14.319)

No, types are not a panacea. They're not like a silver bullet. Just because you're type safe does not mean that you have zero bugs. But it definitely catches a huge category of bugs that would have been much more challenging to catch otherwise. And back end developers want that. And consequently, they want type.

 

AJ (45:25.675)

Yes.

 

AJ (45:31.341)

Yes.

 

AJ (45:36.171)

Yes.

 

Dan (45:42.979)

safe languages for the back end and they don't consider, at least from what I've seen, TypeScript as a sufficiently good candidate in that regard. Whether it's true or not is you can argue.

 

Lane (45:57.684)

So I can chime in here as a backend developer. I could chime in. Yeah, so most backend developers that I would at least work on larger backend systems and not like, you know, monolithic like Ruby on Rails or just Python Django apps, I would argue yes, like as general rule want types. Partly for catching this huge category of bugs, but also just for developer productivity.

 

Like being able to autocomplete properties on objects rather than having to go consult the docs every time. You just move so much faster.

 

Dan (46:30.995)

Yeah, but copilot writes all your code for you anyway.

 

AJ (46:34.542)

Does anybody use Copilot?

 

Lane (46:37.349)

Copilot, I do use copilot. The most annoying thing it does is override autocomplete. They need to fix this. It's the number one reason why I have to turn it off from time to time is like you go to autocomplete a property on an object and GitHub copilot makes something up that's right 95% of the time when the autocomplete would have been right 100% of the time.

 

Charles Max Wood (46:37.725)

I want to.

 

Dan (46:58.291)

So now I have to take us as a short aside about co-pilot with the people at conferences, speakers doing live coding, where half the time it's amazing and it writes for the automatically generates for them the exact code that they want, but half the time it totally doesn't. And then they spend a huge part of their talk deleting stuff, which is really amusing.

 

AJ (47:25.367)

And that's...

 

Charles Max Wood (47:25.492)

I need a sound bite from somebody now that says, that's a tangent, and then we move back to the topic. But yeah.

 

Dan (47:29.691)

Yeah, sorry, I apologize. Yeah, okay.

 

AJ (47:32.64)

No, it's-

 

Lane (47:36.36)

I have to turn it off any time I do a demo. It's, yeah, it's not conducive to that sort of thing. But like to circle back on types, I actually do think that TypeScript is okay as far as types go. If I'm choosing not to use TypeScript on the backend, it's probably not because I don't feel like the type system is expressive enough or something. I don't really have a problem with that. Yes, it's too much work in many cases.

 

AJ (47:57.066)

It's too expressive. It's far too expressive.

 

Lane (48:03.828)

The reason, like if we set performance aside, which is something we've already talked about ad nauseum, the primary reason I code in Go is for the simplicity, right? You can be a lot more expressive in TypeScript than you can be in Go, in my experience. But I don't want to.

 

Charles Max Wood (48:24.052)

Okay, I don't, and this is kind of where, like I haven't written, I can't say I haven't ever written in Go, but it's been like once or twice. And then people get into, I think Rust is another language that a lot of people are picking up for various things, mostly system stuff, but I'm seeing more and more people doing some backend stuff with Rust, whether it's microservices or things like that. And so, I mean,

 

when we get into this discussion about types, right? Cause I write Ruby on Rails on the backend. And so, you know, my typing is duck typing, right? It responds to it. It's one of those. So, which is kind of how JavaScript works in some ways, but...

 

AJ (49:10.442)

remind me is Ruby strong? Meaning if you assign a number, you can't assign a string because Python strong. Okay. Well, that dynamic, you can be dynamically type and strongly typed because you can dynamically assign it as an integer, but it's strong. So you can't reassign it as a string.

 

Dan (49:17.243)

No, it's dynamically typed.

 

Charles Max Wood (49:19.495)

dynamically typed.

 

Charles Max Wood (49:29.376)

No, I can reassign it as a string or a puppet class or whatever. So yeah, it doesn't matter. But yeah, so that's my question is, okay, you know, what do these type systems look like that make you go, okay, I would rather write go than TypeScript, right? Because it seems like those are now into the area where we're solving similar issues, right? With our tooling and stuff.

 

AJ (49:32.104)

Okay.

 

Dan (49:57.079)

Type languages that have been designed with coherent type system in mind have a huge advantage in this regard. I'm blown away by what the TypeScript designers and developers have been able to achieve, but that being said, they're at a huge disadvantage.

 

compared to languages who've had their type system designed from the get-go to be coherent and consistent. By the way, even some JVM languages have a certain disadvantage in that regard, because they're running on the JVM and have certain constraints imposed on them by the JVM itself, because the JVM was designed for Java. But yeah.

 

Anyway, the...

 

Charles Max Wood (51:00.532)

Yeah, I guess, you know, AJ and Lane, at least to some degree, champion Go, right? So let's just simplify the, I'm gonna oversimplify the case for a minute, right? So what is it about Go's type system that makes it superior to TypeScript, right? Cause you said it's more constrained. You said it's more constrained, but yeah, I mean, what-

 

AJ (51:19.414)

Cause it's more like JavaScript.

 

Lane (51:26.824)

First of all, I wouldn't say it's superior. It's definitely less expressive. There's kind of less you can do in Go's type system. And there actually are things I lament about it. I wish that Go had better support for enums, for example. Like that's, yeah, like some types would be great, right? We don't have them in Go, I wish we had them. You could do that in TypeScript, yeah.

 

AJ (51:39.37)

I knew it. We all do.

 

Dan (51:46.331)

On the other hand, enums in TypeScript are a mistake. The enums in TypeScript should not have existed.

 

AJ (51:51.916)

Oh, they're not enums.

 

Lane (51:55.004)

Well, but you can get the idea of enums even if you don't use the enum keyword, right? And those seem to work pretty well, at least in my experience. Yeah, the union type.

 

Dan (52:00.933)

Yeah, you can.

 

AJ (52:01.683)

Yeah, the ore.

 

Dan (52:04.683)

Yeah, the union types.

 

Lane (52:07.216)

Yeah, and that's what I'm talking about. Union types would be fantastic. So I definitely wouldn't go so far as to say Go's type system is better. There's a lot of things to compare when comparing TypeScript and Go on the back end. Statically compiled binaries is actually one of my number one things that you get when you build a Go program. You compile it down into this single binary that has no dynamic dependencies and you can just deploy it anywhere. Whereas with Node, you have to worry about.

 

Charles Max Wood (52:33.516)

We didn't even get into that.

 

Lane (52:35.344)

Yeah, you have to worry about node dependencies and things like that. The interesting thing is that's actually become less of a problem with Docker images and things. And there is, I just want to caveat before I go shilling go too much. There's a huge set of problems that I think are perfectly fine to solve in JavaScript or TypeScript and probably should be. Like AJ said earlier, a lot of applications are going to run at like 5% of CPU and memory utilization,

 

like many thousands of users making millions of dollars a year, just because they're not that like performance intensive, right? Whatever problem is being solved just isn't necessarily bottlenecked by data and scale in that sense. And if your whole application is otherwise written in JavaScript, I see no reason to move away from JavaScript or TypeScript on the backend. You know, you have a team of 10 developers, you're writing React Native and React for your like your web and your mobile. It's like, I don't see a reason to move away.

 

It's really when something else changes, right, that I would move.

 

Dan (53:36.179)

The biggest advantage that JavaScript has over all other programming languages is that you kind of can't get away from using it. I mean, you're going to have a web front end, which means that you're going to have to do stuff in JavaScript. So the main advantage of using JavaScript on the back end is just the fact that you don't need to mess about with more programming languages. That's...

 

Lane (54:03.136)

I think that's true, but it only applies to companies under a certain size. It stays true for a while, but once you have an engineering team of 100, 200, 500, 1,000, now that dependency between just the front end and the API gateway, you don't need all 1,000 engineers working on both sides of the stack anymore.

 

Dan (54:24.315)

Yes, but you do want to be able to move developers between teams. And there's going, and you need to be aware that you'll be paying an ongoing cost in whenever you shift developers between different teams. There's something that would have been significantly reduced had they all been using the same programming language.

 

AJ (54:52.002)

So I think.

 

For mature developers, I think that is very true. For beginning developers, which is most developers, I think it's actually better to have a separate language on the backend than on the front end, because people get confused about which is which, especially in the frameworks where they try to share an autoload components that

 

And you have like a is browser function or like stuff like that. It's people get very, very confused about what's front end and back end. And also some point number one, that point number two.

 

Dan (55:36.467)

Uh, wait a minute. So like the problem of deploying your secrets to the front end.

 

AJ (55:43.326)

Yeah! Yeah, that's one of them.

 

Lane (55:47.708)

this problem. I started web development in Python Django and everything was just one big monolith where we're doing template rendering to the front end and I was so awfully confused as a new developer trying to figure out what code's running on the front end, what code's running on the back end, how do I load secrets. I was like Googling things like nonsensical stuff like is X feature secure because I have no idea. And the minute I started writing very decoupled back, and I'm not saying decoupled architectures are what you need from a business

 

From a learning standpoint, it helps me so much understand the architecture of the web.

 

Dan (56:22.975)

By the way, what are you using on the back end? Go.

 

Lane (56:27.356)

At Boot Dev, yeah, we're using Go on the back end and View3 on the front end. It's a single page application.

 

AJ (56:34.658)

So the second point I was going to make there is that when you have two languages, I think it helps people cement ideas better because you hear new developers. They'll talk about, you know, I know how to do a loop in JavaScript, or did you know that JavaScript has loops? It's like, yep, that's, that's what a programming language is. They all got them. But, but, but

 

Seriously, having working with two different languages helps people figure out what's hype versus what's programming. Because the things that you see across both languages that you can figure out that's programming. And the stuff that only exists in one oftentimes is hype or framework.

 

Lane (57:26.172)

Yeah, now we're getting a little bit into like developer education, which I love, you know. But I completely agree. I think most developers should learn at least two programming languages, like pre first job. I think the idea that you need to, not 10, right? I learned like 10. I learned like 10 in my CS degree. It was way too many. But I think one is also a mistake for exactly a lot of the reasons you just outlined, AJ. It's like, you don't know the distinction between a concept and a feature of a language.

 

Charles Max Wood (57:30.752)

Mm.

 

AJ (57:39.442)

not 10 not 4

 

Charles Max Wood (57:42.424)

Ha ha ha!

 

AJ (57:54.507)

Yes.

 

Lane (57:54.924)

And that's the distinction that I want new developers to pick up on, right? So learn JavaScript and Go, right? Learn Python and Rust, like whatever. It's even better if the languages are a little different, compiled versus interpreted, for example. You start to pick up on some of this stuff.

 

Charles Max Wood (57:55.16)

Mm-hmm.

 

Dan (58:10.536)

Yeah, but there's a huge difference between learning a language and decide to build your production environment in this particular programming language. Yeah, you're making a significant commitment when you decide that, yes you are, because for example at Next, again, when we decided to use Kotlin on the backend, we're kind of unique in that.

 

AJ (58:21.023)

Python.

 

Dan (58:38.115)

And that means that every backend developer that we bring in needs to undergo training and learn the language. Now, it's not that bad, especially if you're coming from a Java background. In fact, a lot of Java developers really appreciate the fact that Kotlin does away with a lot of the Javaisms and a lot of the boilerplate, but still.

 

It's a non-trivial effort investing in training of new developers, and it takes time until they can actually be productive and contribute into the code base. And that's a tax that we pay.

 

AJ (59:21.065)

Yeah, I-

 

Charles Max Wood (59:21.1)

You know, you talking about that Dan, just reminded me that there really is a perfect framework. It's written in Swift. It's called perfect. Anyway.

 

Dan (59:30.888)

Hahaha!

 

AJ (59:31.862)

Oh, okay. Well, like, I, I think, I think people should be okay with learning Python for 30 days and then throwing it away and never touching it again. Like it is a great language to learn. And I think that's more what I'm getting at. I'm not talking about, cause there's learning the language. And in this case, I literally meant language, which often when we say language, what we mean is learn the language, the tooling, the standard library and the, the core.

 

Charles Max Wood (59:58.946)

Right.

 

AJ (01:00:01.238)

Web framework. That's when we say I'm going to learn JavaScript. We mean those four or five things. We say I'm going to learn go. You don't have a choice. You are learning those four things. But when I'm thinking about just learning, which again is a very, a very brief and incubatory period of a person's career that it when learning, learning the language has value and just learning the language, just to.

 

what we were talking about before, but I completely agree with you.

 

Dan (01:00:32.828)

I have one question I want to throw to you guys before we run out of time. And that again goes back to a very specific use case of the backend. And that question is, do you think that the new JavaScript frameworks will be able to finally supplant PHP?

 

AJ (01:01:01.526)

They've already got it.

 

Lane (01:01:04.553)

Well, as long as WordPress is here.

 

AJ (01:01:04.662)

Why, we don't need to turn JavaScript into PHP, they have PHP.

 

Lane (01:01:09.492)

So Ghost is like the new CMS written in Node, right? Like, I can't remember the percentage of like websites that are still just like run on WordPress. I think WordPress is almost single-handedly keeping the PHP ecosystem alive with like a supporting arm being offered by Laravel, right? I think yes. I think eventually PHP.

 

Charles Max Wood (01:01:10.155)

Yeah.

 

Lane (01:01:36.848)

I think the time of death on PHP is going to be very long. I think it'll be around for a long time, but I think every year, Node steals more and more of that market share.

 

Charles Max Wood (01:01:49.08)

It's interesting though, because when you're talking about WordPress, um, right. So I'm involved in a number of organizations that use WordPress for their website. And the reason is, is because we have non-technical people that either, you know, they're the ones working in it, or it's a volunteer organization where it's like, Hey, you can go Google the crap out of, out of do the thing on WordPress. Right. And they can find it. And then if there's some technical component to it, they can either ask me to help them or they can find somebody who can do it.

 

And so yeah, I think that's the long tail on WordPress. The other thing though is I also see, how do I put it? So it's not just the frameworks, the backend frameworks, that's part of it. But I think the other piece is a lot of the node code, no code tools are getting better. And so then it's not just, hey, I need, because people's needs on their websites are becoming more sophisticated.

 

and we're adding new stuff all the time, you know, when it comes to like, I want this machine learning driven feature, or I, you know, I need, I wanna take donations on a cryptocurrency or things like that, right? And so you need some other thing added to it and we're consistently adding, you know, things to that pile of stuff that you may want on your website. And a lot of these no code tools are opening up some of those possibilities as well.

 

Dan (01:02:49.855)

How are we?

 

Charles Max Wood (01:03:15.396)

And I don't think people are writing those in PHP. I think people are writing those in other languages that are more approachable and that allow them to express what they want better. And then, right, they can present that or present an API for somebody else to build the no-code tool that will actually do it. And so I think that's another piece that's gonna come out of it. And then I think we're also moving into an era where I don't see people moving away from the web per se, or even the web browser per se, but a lot more people.

 

are bringing a lot more things to, we may have a breakthrough in VR, for example, and AR and how people interact with the web that way. And that may be another thing that may or may not come about that will open up possibilities. So I think there are new technologies that are gonna open some of this up as well. And we're gonna say, hey, we don't need the traditional PHP backend rendered HTML the way that WordPress does it. As far as the rest of it goes though,

 

I think anything that's custom built, yeah, I think more and more people are moving away from PHP with the notable exception of Laravel.

 

Dan (01:04:19.931)

Yeah, by the way, just to clarify, I did not mean that I think something like, uh, next JS will replace the PHP inside of WordPress. Obviously that will never happen. I, I meant in those scenarios where you actually are looking to develop some sort of, of a custom web application or sophisticated website that's not built on top of WordPress. And, you know, in the past.

 

might have used PHP and these days are much less likely to, but there are still PHP developers out there. And the funny thing is that if you look at what the React is doing and React Server components and whatnot, a lot of it is like quote unquote, for better or worse, PHP inspired.

 

Lane (01:05:12.604)

That's what I'm seeing. So like if you look at Vercell, which obviously backs Next.js and is kind of a hosting platform, I would argue they're pushing for more features that are like domain specifically good for things that WordPress and Shopify have done in the past, right? Things like e-commerce, right? I hit this landing page, it needs to load instantly. That's why server-side rendering is really great for that use case. So I tend to agree. I think a lot of investment is being made.

 

in the JavaScript space, specifically in the Next.js space, for things that a lot of people are using WordPress for today. And I think Next is definitely moving in that sort of a direction. And I would argue, in the same stroke, it's making less of an emphasis on web applications that you'd typically build in the B2B SaaS space, for example.

 

Charles Max Wood (01:06:05.752)

All right, we've got to kind of get to picks.

 

AJ (01:06:09.046)

Do we though? Can we run longer?

 

Charles Max Wood (01:06:14.586)

I don't have anything scheduled right after this, so I guess we could.

 

Dan (01:06:17.139)

And I don't have any pics. Ha ha ha.

 

AJ (01:06:18.046)

I'd at least, I'd at least like to, to get lane to go through his nine questions here and, and give a, I mean, we've talked about most of this.

 

Lane (01:06:26.297)

Ha ha!

 

Yeah, I have to be off it at one. So I've got 13 minutes, but I can go through some of these.

 

Charles Max Wood (01:06:29.318)

So we're gonna be here for another hour.

 

Charles Max Wood (01:06:36.105)

Okay, so.

 

AJ (01:06:37.712)

Can you give us 30 second answers for what you believe on this stuff? When would you use JS on the backend? What's the case for it?

 

Lane (01:06:44.092)

Yeah, so as I alluded to earlier, primarily because I have no constraints stopping me from using JS, or honestly, I'd probably use TypeScript. But when I have no performance or practical constraints stopping me, and my front end's already written in JavaScript, and my team already writes JavaScript, so it would be a very team-oriented choice. But that's the only time I do it. I'd probably pick Go as a default if I didn't have a heavy JavaScript team that I was working with.

 

Dan (01:07:08.735)

So you would not have any JavaScript on the backend, not even as middleware.

 

Lane (01:07:14.844)

I don't think so. I would probably do what I have now, which is I have a REST API written in Go, I copy my structs into a little web tool to get the TypeScript interface for them, and then write TypeScript on the front end.

 

Dan (01:07:28.291)

And you're not going to be using any sort of a meta framework, like Nuxt or Next or something like that.

 

Lane (01:07:37.088)

If I'm building a website that needs to have really fast first page load, so like an e-commerce website, for example, or like a blog, then yeah, I'd probably use a meta framework for like server-side rendering reasons. But if I'm building a SaaS application where it's like the first load can be a little slower, and when I say a little slower, I mean like just 50 milliseconds or something, right? Like this isn't crazy amounts we're talking about.

 

Dan (01:07:56.203)

That's... If you're doing, if you're not doing a

 

Kind of depends on what

 

Lane (01:08:03.228)

depends on the latency of your network requests, right? Like you load the JavaScript and then you make a request.

 

Dan (01:08:05.635)

Yeah, let's put, I'll phrase it differently. If you're doing CSR, that means you're sending down a blank HTML and doing all the rendering on the client side, you are going to, almost by definition, you're going to have performance issues. Now you might not.

 

Lane (01:08:26.46)

Well, it depends on how you define performance issues. You take a hit upfront, but then if you're running like a B2B app, like take for example, Jira or Linear, where people are spending lots of time in the application, you get a ton of performance benefits on the backend, right? Because people are spending an hour in your app.

 

Dan (01:08:37.295)

Oh yeah, for sure. I like that.

 

Dan (01:08:43.106)

If your page does not need to have a good metric here, is if that page will never be indexed, then you might not care.

 

Lane (01:08:55.908)

Exactly. So that's where I would draw the line as well. Like if I'm, if I need SEO and really fast page loads, yes, I'd probably reach for a MetaFrame.

 

AJ (01:09:05.006)

Alright, so when would you not use JS not just because of personal preference, but like what's it, you know, you know,

 

Lane (01:09:13.212)

Yeah, yeah, yeah. So setting personal preference aside, like I mentioned earlier, if I'm doing a lot of compute on my server, right? So in the past, I've worked on a project, like I said, where we were kind of ingesting thousands of tweets and Reddit posts and Facebook posts per second, and looking for keywords and doing spatial matching and things like this. And so by using a language like Go or Rust, if I needed even more control,

 

I get more control over memory and it's frankly just cheaper. At least it was a few years ago when I did it. I'm assuming that would still be the case, but generally it would be for performance reasons.

 

AJ (01:09:55.862)

And I think we've already kind of talked about trade-offs between go versus JavaScript, but is there anything else you wanted to add on that note?

 

Lane (01:10:03.528)

Just to sum it up really simply, if the bottleneck is I-O, then switching to Go isn't going to get you any performance benefits, probably. The difference between Go routines and promises, it's fine, it's not a big deal. It's really just if your CPU utilization is bumping up into 80% of your pod or your server or whatever, now you might see some reasons to switch to a compiled language.

 

AJ (01:10:25.738)

which brings us directly into, is single threadedness a problem in backend applications?

 

Lane (01:10:34.544)

I don't, like counter-intuitively, I don't think it's a problem for I.O. In fact, I think it's, you actually get a lot of performance benefits by using this sort of an async await approach to doing things at the same time. As long as those doing things at the same time is like reaching out over a network or going to disk or something like that. Yeah, go ahead.

 

AJ (01:10:56.01)

I'm going to, I'm going to add to this. Go was invented to solve a problem that we immediately stopped having in some regard, not, not all of go, but specifically it's go routine model, which is by the time they actually got go routines stable and landed working the way they were described in the original conference talk five years prior, they were useless because we don't run multi-core systems anymore.

 

you deploy and it runs on multiple instances, multiple single core instances, where they're actually not even single core instances, they are one half of a hyper thread.

 

Lane (01:11:34.352)

Yeah, I completely agree with that. Right? If you're using Kubernetes, you just scale up at the pod level, right, rather than within your application. Though I will say, there's been a lot of times where it was really nice to be able to just run a quick background job on the same server, for the reason that I don't need to reach to the infrastructure to solve the problem for me. That doesn't mean you should never reach to the infrastructure. Sometimes serverless stuff or Kubernetes really are good for those things.

 

Charles Max Wood (01:11:41.016)

Right.

 

Lane (01:12:01.32)

But it is kind of nice to just be able to like, I'm just going to spawn a go routine and do it here.

 

AJ (01:12:05.45)

Yeah, but it but in general, like the in process concurrency, ridiculously important in process parallelism, not actually that

 

Lane (01:12:20.724)

Yes, in web servers, yes.

 

Charles Max Wood (01:12:24.804)

If we're gonna get through these questions, we gotta go faster.

 

AJ (01:12:24.947)

Okay.

 

AJ (01:12:28.374)

There's only five left. Is JavaScript dynamic typing a problem should it be solved by TS, JS doc, or just switch to go? Okay, all right.

 

Dan (01:12:34.252)

We discussed that. We can skip that.

 

Charles Max Wood (01:12:36.429)

Yeah.

 

Lane (01:12:37.5)

Yes, and you can Google my blog post if you want to hear the whole tirade.

 

AJ (01:12:40.19)

Yeah, put the link in if you if you wouldn't mind. What about the advantages of having a node JS server that serve the app front end as the same server, especially when using Next or Next? I think we kind of touched on that. OK.

 

Charles Max Wood (01:12:52.012)

I think we hit that one too.

 

Lane (01:12:53.596)

We hit that one, yeah. Meta framework if you need SEO and fast initial page load.

 

AJ (01:12:58.686)

All right. Uh, and then this one, I think we hit as well. Is it more important to have backend plus front end in the same language or all backend services in the same language with that, that I didn't. Not quite sure what you meant by that, but I think we kind of touched on it.

 

Lane (01:13:12.008)

Yeah, in a single sentence, I'll just say, my opinion is if you're on a very small team and everyone already knows JavaScript, great. Stay in JavaScript and TypeScript. As the team grows, it becomes less important.

 

Dan (01:13:21.515)

I need to add one thing and throw it in here. And that is if you're running a high capacity service and then it crashes or the memory balloons or you have these sort of problems, you might be happy that you're not using JavaScript if those things happen. Because the tooling to deal with these things in JavaScript is not...

 

up to the level of other solutions that are out there.

 

AJ (01:13:55.378)

Yeah, it's kind of designed assuming that you've got a Mac studio with 128 gigs of RAM and you know that can handle your three Chrome tabs for you.

 

AJ (01:14:08.331)

dry humor anyway. So the mental model, the async await versus go routines. Does that change how you think about concurrency?

 

Lane (01:14:16.74)

It absolutely does. And just to sum up this up really quick, the difference is that in Go, everything is synchronous by default. If you make an HTTP request, congratulations, you're waiting around until that HTTP request comes back. Whereas in JavaScript, it kind of just gets fired off and you have to await it or.then the promise if you want to deal with something when it comes back. And those are two very different models. I don't have time right now to go into the benefits, but.

 

It's just a very different way of doing it. And if you learn both models, I think that could be a huge advantage to have as developers.

 

Dan (01:14:49.227)

for sure.

 

AJ (01:14:49.606)

And I just want to say on that the go way of doing it is generally speaking more efficient because you're allowing the operating system to do things that it's going to do anyway, like the first time you fetch a file, the first chunk of a file. Yeah, it kind of needs to be synchronous, but every subsequent read the operating system already put it in cash for you. So doing asynchronous is actually slowing you down and the go routine model.

 

of letting the event loop handle it at that layer rather than always offloading it. Seems to make more sense.

 

Dan (01:15:23.655)

I'll put it in a simpler sort of a way. If you're just, if all your development experience is in JavaScript, then you don't know what thread pools are. And if you don't know what thread pools are, then you're like, you have like really missing, significant knowledge missing in your arsenal.

 

AJ (01:15:44.85)

And then the last question that should have been number three, even though GraphQL is irrelevant and dead and nobody's using anymore, uh, does it matter in this discussion? Does it, does its existence change anything?

 

Dan (01:15:53.633)

hahahaha

 

Lane (01:15:56.177)

Ha ha ha! Uh... Because we have three minutes left? No, not really.

 

Dan (01:16:02.867)

I would throw to that though, that, and we kind of touched on it before we invited everybody on and before we started this entire recording, is that GraphQL might be going away in many or most cases, but RPC is making a huge comeback. And everybody seems to be embracing RPC all of a sudden. And that has significant implications to what you're using.

 

on both sides of the RPC invocation.

 

AJ (01:16:39.446)

And I, I would add to this, uh, if you're going to do something like graph QL, you should only use JavaScript because it's so dynamic that trying to manage and go as an absolute nightmare. Am I wrong? Any, any type. Yeah. Type languages and, and yeah, it, yeah, it's that one. Yeah. All right, we're done.

 

Lane (01:16:52.128)

Agreed.

 

Charles Max Wood (01:16:53.089)

It's also a nightmare in rails.

 

Lane (01:16:58.063)

It was built for JavaScript by Facebook. Like you just, yeah.

 

Charles Max Wood (01:17:03.968)

Yeah, yeah, in Rails, you write your Rails app, you write your another Rails app so that it'll do GraphQL within your Rails app, so it messes your code up, and then you write your JavaScript app to consume it.

 

AJ (01:17:14.246)

Yeah, it's like Apollo or Bust.

 

Charles Max Wood (01:17:17.876)

Yeah. All right. So we do have a couple minutes, Lane. Do you have some picks?

 

Lane (01:17:24.016)

Yeah, I'll start with my plugs, because those are easier. If you're interested in learning back-end development, back-end banter.fm, that's my podcast. Chuck was on recently, it was a great episode. And boot.dev, if you're looking for an interactive way to learn Python and Go, specifically tailored for web development. My pit, yeah.

 

AJ (01:17:43.53)

And that was back-end banter, not back-end dancer, right? Because it definitely sounded like he said dancer.

 

Dan (01:17:47.699)

Hahaha!

 

Lane (01:17:48.722)

Backends banter.

 

Charles Max Wood (01:17:50.585)

I was so on the dancer train, let me tell ya.

 

Lane (01:17:54.46)

You'll get something very different if you look for back-end dancers. Yeah, backenddancer.fm. And then for my pick really quickly, there's this really cool YouTube channel that I just found called CodeAesthetic. And he's only put out like six videos and they are amazing. Like, you can tell he's put an insane amount of work into these videos. He's explaining different software engineering concepts with beautiful animations. So CodeAesthetic, check that out.

 

Charles Max Wood (01:18:23.688)

Awesome. Okay, one more thing if people want to follow your lane, where are you?

 

Lane (01:18:28.152)

Boot.dev, you can sign up for the mailing list. That's free to sign up. Backendbanner.fm, already plugged that. And yeah, those are the best places. I'm at Wagslane on Twitter if you wanna tweet at me. Or Zete, Xeet. At me.

 

AJ (01:18:38.902)

Those are the spicy takes.

 

Charles Max Wood (01:18:43.712)

Yeah. Yeah, I saw somebody spell it with like X itter and my brain. Yeah. But I saw somebody kind of mix the two and my brain put the sound for the X. And so then I was off on a completely other anyway. Um, all right. Well, uh, lane, if you need to drop out, cause it, it is one o'clock. Uh, we're.

 

Dan (01:18:46.303)

That's a new verb?

 

AJ (01:18:51.655)

It's x.com. Did you all not know?

 

Charles Max Wood (01:19:13.368)

Glad you came and thanks for making us argue with each other. Um, and yeah, we'll get picks from everyone else and we'll bail out.

 

Lane (01:19:18.644)

Thanks so much, yeah.

 

Talk to you guys later. It was great hanging out and jabbering.

 

Dan (01:19:24.195)

Yeah, great conversation. Thank you.

 

Charles Max Wood (01:19:26.509)

Yeah.

 

All right, Steve, do you have some picks for us?

 

Lane (01:19:29.184)

Thanks, bye.

 

Steve (01:19:32.302)

Well, as I stated at the beginning of the show that I contributed so much to today as a PHP developer, I was insulted. But I do want to go back to Better Off Dead, which is an all time cult classic. So many one liners. I have multiple shirts from that movie that my kids have gotten me over the years. I have even passed on my love of the movie to my kids, friends and to other adults. So.

 

Well worth a watch, very highly intellectual too. And then second are the dad jokes of the week, which are the highlight of, I like to say the highlight of every episode. It's up for debate. Dan and I like to debate those things. So first of all, the other day, my neighbor knocked on my door at 2 a.m. and said, I can't sleep. I said, well, it's your lucky day. We got a party going on in here, come in.

 

Steve (01:20:33.99)

It was like the other time when I had to stop the drums to let somebody in at 2 a.m. Random thought for the day, expiration dates are spoiler alerts.

 

Steve (01:20:46.602)

Right? And then finally, what do you get when you cross a dolphin with a lion fired from the zoo?

 

AJ (01:20:57.474)

Give me a chance to wake up, sweetheart.

 

Steve (01:21:04.43)

Nice. Where did that come from?

 

Charles Max Wood (01:21:04.492)

All right, Dan.

 

What are your picks? I don't know.

 

Dan (01:21:09.791)

Okay, so I do I have managed to think about a pick or two. So first of all, I'm kind of rewatching Silicon Valley, the TV show, and I'm enjoying it a lot. And so I'm going to recommend it. Yeah, obviously, certain parts of it have aged, but it's still highly amusing and surprisingly accurate.

 

at depicting a lot of tech culture and phenomena and whatnot. So that would be my first pick.

 

Steve (01:21:49.146)

Yeah, I was listening to another podcast yesterday, pretty well known one, and they had a couple people on. I can't remember if they are part of the show or not, but they were talking about some of the scenes from there and how real life they are. I think one of them they talked about was two startups that somehow merged or two companies that merged and everything was fine. But the biggest fight they had was the discrepancies between the dog policies between the two companies where one encouraged dogs to come in and the other said no dogs at all.

 

Charles Max Wood (01:22:16.698)

hahahaha

 

Steve (01:22:19.206)

It's supposed to be a real funny episode.

 

Dan (01:22:20.495)

It is. And I remember they're like at this conference and one of them who says he went to a great party, there were 12 girls there.

 

Charles Max Wood (01:22:33.592)

Uh-huh.

 

Dan (01:22:34.019)

Okay. Yeah. Anyway, so that would be my first pick. My second is something that I actually picked like in a previous episode, but you weren't on, so I'll pick it again. I know you're into also fantasy books, and I'm reading one that is really growing on me, which is called the Faithful and the Fallen series.

 

It's by John Gwynne. I think it's all been released, so there's not a problem of reading three books out of the four and then the fourth one never coming out. At least you know getting in that you'll be able to read it till the end. And like I said, it's really grown on me and I'm enjoying it a lot. It's mostly well written and it's engaging and the interesting characters and lots of action.

 

Uh, and it is kind of bloody and gory. So do take that into account Uh people keep chopping each other's heads off Uh, but other than that, uh, it's pretty good and uh certainly not as much, uh gratuitous just uh sex as uh as in uh You know songs of ice and fire So so yeah

 

So that would be my second pick. And my third pick. Well, actually it's not really a pick. It's a commentary. It's the ongoing war in Ukraine. It's still there. It's still ongoing. Please do whatever you can to help the people in Ukraine. And those would be my picks for today.

 

Charles Max Wood (01:24:21.16)

Awesome. AJ, what are your picks?

 

AJ (01:24:25.102)

Oh, I've got some good ones. All right. So first off, I'm going to give another shout out to socket security, uh, which if you want to follow their ZEETS that's X.com slash socket security. And if you want to install it, uh, it's, uh, I, I have to, I have to remember what that is every time because yeah, but it's, I don't remember the stylization of it, whether it's a hyphen or not anyway. Uh, but so.

 

If you add it on GitHub, it follows your PRS for node projects, things that have a package dot Jason, and it will tell you if you have a mistype something. Cause there's, there's the misspelling attacks. So I'll tell you if, Hey, it looks like you installed this that has this many. Uh, dependent this many things depend on, but it looks like it's really similar to this thing that this many things depend on.

 

Are you sure you meant that? So it comes up as part of the PR process. It'll audit your package dot Jason and, and warn you of things like that. They follow CVS. They, you know, you just, it's, it's just, I don't know that there's anything else to do to be responsible other than what they provide. They like, you need to be using it. And when you install the command line tool, I'm kind of 50 on this one because

 

Sometimes it seems like it makes NPM install go 1000 times slower. Uh, and I think it might be more when you're installing a package that isn't Uber popular, that it, maybe it has to go parse and figure out everything and follow its chain or something like that. But I noticed sometimes when I do an NPM install after installing their, their socket alias for NPM, uh, it.

 

And then also NPM audit fix doesn't work the same. So it's, it's kind of 50 on that one. I don't know if the costs, the benefits outweigh the cost, but they do have an NPM alias that you can install and then it will run as a developer before you get to the PR process, it will run those checks and let you know if something looks fishy or, you know, there's it's a malware package or whatever. So, and, and I like, I like a lot of what. Uh,

 

AJ (01:26:51.602)

For us is doing with that. It just, he's got a lot of good approaches. I really think are, are that are very reasonable. If not the best way to go about it with the, you know, the best trade-offs of trying to figure out heuristically how to determine what's malware and what's real and everything. And I've, I've only had good experiences with it so far. So shout out to them. Also coffee. Zilla is a new podcast.

 

Well, it's not it's not it's not episodic, but it's a YouTube channel that you can listen to. You don't have to watch it. And he goes over every scam that happens in the Internet space. Almost all of it is cryptocurrency related. But it's just enjoyable is it is an investigative journalist for real, but has put some flair in the show. So he has he wears suspenders. He looks like a.

 

noir style detective, but the stuff he's doing is real. He's actually accessing resources that journalists would have access to, to get accurate information and fact checking things and does interviews with people and all that. So he's the right mix of reporting on the facts and being entertaining without being fake, I think. And so shout out to, well.

 

I pick the Coffeezilla channel on YouTube. And then also I talked about this. Well, actually I don't know if I mentioned this. I mentioned the chat, but JS with types. I did a presentation called JS with types and the essence of it is that you can get the TypeScript checker to work on JavaScript and have typed JavaScript. Now, unfortunately TypeScript doesn't fully support JavaScript's native types. They're more concerned with the extension of the types that are more similar to C sharp.

 

but it actually is getting better. I think between TypeScript version four and TypeScript version five, I think is the latest one. There were some significant improvements that I noticed in the type checking where it would generate false negatives or false positives for errors far less often. But you could never remember.

 

AJ (01:29:12.15)

what you need to do in order to get this working. Like you could never just start a project with TSC init and then edit it by hand or pass the right command line options to get it to work. Cause there's one, two, three, four, five, six, seven, eight, nine, 10, like 11 or 12 different things that you have to pass to get the TypeScript checker to work with a JavaScript project plus changes to the TS config.js. Anyway.

 

So I did this talk and I created this little NPM module that just sets up your project with the right config file and project structure. So you can just go to work and have types just magically turn on in your editor, whether that's VS code or VEM. And so I I'm putting a link to that, but the, the presentation is JS with types.com and the package that does the init for you passing the 11 or 12 options. And then the

 

three or four updates to the config file is JSWT or JS what.

 

Charles Max Wood (01:30:16.188)

Okay. That sounds cool. Kind of want to go play with it.

 

AJ (01:30:20.162)

Friends don't let friends JavaScript without types.

 

Charles Max Wood (01:30:25.205)

Alright, I'm going to jump in with a few picks. I don't remember if I picked this game last time or not, so I'm going to pick it. And if you get two weeks in a row, I'm sorry. The game is called Living Forest. And... How do I describe it? It's kind of a...

 

So there are a couple of different resource types that you get that you can use to buy cards or trees. It's a nature-based game. It has a board game weight of about, of 2.21. So it's, you know, if you're a casual board game player, you can definitely play this game. It's not that complicated. You win by getting the right kind of tokens, right? So you have, there's like the little lotus flower. You get 12 lotus flowers.

 

Um, right. It ends the game and then anybody else who got 12 of the other, any of the other, any of the other types of tokens, right. Then you do a tiebreaker. Uh, you get flame tokens. And the idea is, is there's a fire spirit that is. You know, burning up the forest. And so, you know, you can use your water resources to put out fires. Um, if you have enough water resources, more water resources than the amount of fire out there, then you're safe. And if not, then you get a.

 

a card in your deck is kind of a penalty. It's a little bit like I can't remember the other. It's another. A game that's similar where you're laying out cards and you get to a certain number of a certain kind of card and then your round is up. Uhm? But yeah, there are trees. So you're planting trees in your forest. If you get 12 different kinds of trees, that's another one of the tokens.

 

But yeah, so as soon as somebody gets 12, everybody, you finish the round that you're on, and then anybody that has 12, then you add up all of the different tokens that count, you know, that you can get 12 of to end the round, and whoever has the most of those wins. It's pretty straightforward that way. But the different trees give you different kinds of resources, the different cards give you different kinds of resources. The more resources you have, the better trees or cards or whatever you can plant or put into your deck.

 

Charles Max Wood (01:32:41.648)

So it is a deck building game, but it was fun. It was a lot of fun. I think we played it in like an hour and That was just because I was learning how to play and I kept you know overthinking what I was doing Board game geek says you can play in 40 minutes. I would assume that once you know how to play Yeah, you probably get through it in 40 minutes. I think if everybody's learning you're probably an hour ish. There were three of us playing But yeah, way fun way fun game. So I'm gonna pick that

 

Um, another pick that I have, and this is just purely me, uh, and what I've got going on. So, um, they built a, an LDS temple, um, here near me, um, in Saratoga Springs, Utah. And, uh, I'm going to be, uh, an ordinance worker in the temple. And so I'm just excited. Um, it's going to be awesome. If you are curious about, um,

 

what we do in the temples, and you're gonna be in Utah sometime next year, my understanding is that the Oram Temple will also be doing an open house, and you can actually walk through the temple, and they explain what we do in the temples. We typically don't talk as much about certain details of what goes on in the temple, just out of reverence for what we do there, but you can walk through, and we'll explain what we can about what we do there. So.

 

And it's a terrific opportunity. And I think they're looking at opening the open house sometime in the spring. So the Saratoga Springs open house is closed and it's gonna be dedicated here in a couple of weeks. But I'm super excited about that. So yeah. Mm-hmm.

 

Steve (01:34:25.371)

So Chuck, a couple of questions there. So how does it work that an open house is closed? I mean, a little oxymoron there, right? You said the Saratoga Springs open house is closed. It's like, oh, okay. I thought open and closed seems sort of a dichotomy there. Oh, okay. And then the second question was, you said you're an ordinance worker. Does that mean you're dealing with explosives and bombs or?

 

Charles Max Wood (01:34:33.621)

No, what do you mean?

 

Charles Max Wood (01:34:37.693)

Oh, it's over. They're not doing it anymore.

 

Yeah, yeah, it ended a couple weeks ago.

 

Steve (01:34:53.312)

or what's an ordinance or.

 

Charles Max Wood (01:34:53.32)

Right, so the ordinances or the ceremonies, kind of like baptism or, you know, right, things like that. So other churches call them like sacraments and things like that.

 

Steve (01:34:58.217)

Oh, okay.

 

Steve (01:35:03.835)

Oh, sounded like a real explosive job, so I wasn't sure. Thanks.

 

Charles Max Wood (01:35:06.592)

Right. Yeah. So, anyway, I'm excited. So it's going to be awesome. Besides that, I've been listening to the Expanse books on Audible and I really enjoy those. Those are really good. And yeah, I think that's all I've really got today. So we'll go ahead and wrap it up.

 

Dan (01:35:31.432)

I'm just...

 

Charles Max Wood (01:35:31.768)

Thanks for sticking around for a little extra. Oh, what do you have, Dan?

 

Dan (01:35:35.495)

No, no, sorry.

 

Charles Max Wood (01:35:40.94)

All right, well, we'll wrap it up. Until next time, folks, Max out.

 

Dan (01:35:44.607)

Bye. What I wanted to ask Chuck, and this can be asked post upload is, I'm just curious when you're listening.

 

Steve (01:35:45.303)

Adios!