Charles Max Wood (01:27.9)
Hey from a hot and sunny Tel Aviv.
Charles Max Wood (01:46.985)
Yo yo yo, it's Overcast.
Charles Max Wood (01:52.962)
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?
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.
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.
Charles Max Wood (03:08.221)
Steve, I want my two dollars. Anyway.
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)
kind of set the stage for us.
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.
Yes, I agree.
You're muted AJ.
Charles Max Wood (04:44.52)
Yeah, yeah, he's still muted.
Yeah, AJ is at his best when he's muted.
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.
Charles Max Wood (05:26.092)
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
Charles Max Wood (06:22.036)
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.
Charles Max Wood (06:43.167)
Charles Max Wood (07:50.296)
Well, they used to have Rhino as well that ran on the JVM.
Charles Max Wood (08:54.965)
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.
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?
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.
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.
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.
No, it's like adapted to V8, to be precise, V8.
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.
Charles Max Wood (12:53.036)
Charles Max Wood (13:02.368)
Charles Max Wood (13:18.38)
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.
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)
specifically designed for a particular, I won't say use case, I would more say application development model for web applications.
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...
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.
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...
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
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.
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.
That's an interesting-
What if it's because it's the developer's pet language?
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.
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.
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.
Charles Max Wood (22:58.84)
It's always the case.
The answer is yes, it is.
Charles Max Wood (23:28.492)
Figure out where we're headed.
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.
Charles Max Wood (26:09.097)
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.
Yeah, don't do that.
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?
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
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.
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.
Charles Max Wood (28:55.436)
Yeah, there's some good ones.
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
Well, we can't trust them. They're writing Java.
Charles Max Wood (30:49.337)
Charles Max Wood (32:17.348)
like image processing or something.
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.
Well, it's not even necessarily magic. It's just if you don't do stupid. I mean, like.
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.
Yes, yes. Yeah, yeah, I think that that's.
Charles Max Wood (34:04.961)
You're talking about like turbo repo and stuff, right?
Yeah, you can.
Charles Max Wood (35:04.172)
Hey! Oh, sorry.
Charles Max Wood (35:10.143)
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...
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.
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.
Charles Max Wood (38:47.244)
I'm hearing that a lot more often, the type safety.
Types are amazing. Don't code without them.
really difficult to express as in type safe ways. Yeah.
Charles Max Wood (40:28.396)
Lane looks like he wants to chime in. Yeah, there you go. Ha ha.
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.
You're the guest! Hahaha!
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?
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.
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.
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.
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.
Yeah, that's it.
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 tools don't have type safety. Cause C doesn't have type safety, right? Type safety is in the tooling.
What do you mean?
Well, who's using C on the back? Yeah, who's using C on the back end these days?
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!
Yes, but most-
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.
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.
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.
Yeah, but copilot writes all your code for you anyway.
Does anybody use Copilot?
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.
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.
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.
Yeah, sorry, I apologize. Yeah, okay.
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.
It's too expressive. It's far too expressive.
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,
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.
No, it's dynamically typed.
Charles Max Wood (49:19.495)
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.
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.
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-
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.
I knew it. We all do.
On the other hand, enums in TypeScript are a mistake. The enums in TypeScript should not have existed.
Oh, they're not enums.
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.
Yeah, you can.
Yeah, the ore.
Yeah, the union types.
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.
It's really when something else changes, right, that I would move.
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.
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.
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.
Uh, wait a minute. So like the problem of deploying your secrets to the front end.
Yeah! Yeah, that's one of them.
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.
By the way, what are you using on the back end? Go.
At Boot Dev, yeah, we're using Go on the back end and View3 on the front end. It's a single page application.
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.
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)
not 10 not 4
Charles Max Wood (57:42.424)
Ha ha ha!
Charles Max Wood (57:55.16)
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.
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.
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.
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)
what we were talking about before, but I completely agree with you.
They've already got it.
Well, as long as WordPress is here.
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)
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.
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.
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.
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.
Charles Max Wood (01:06:05.752)
All right, we've got to kind of get to picks.
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.
And I don't have any pics. Ha ha ha.
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.
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)
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?
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.
And you're not going to be using any sort of a meta framework, like Nuxt or Next or something like that.
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.
That's... If you're doing, if you're not doing a
Kind of depends on what
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.
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.
Oh yeah, for sure. I like that.
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.
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.
Alright, so when would you not use JS not just because of personal preference, but like what's it, you know, you know,
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.
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.
which brings us directly into, is single threadedness a problem in backend applications?
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.
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.
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)
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.
Yeah, but it but in general, like the in process concurrency, ridiculously important in process parallelism, not actually that
Yes, in web servers, yes.
Charles Max Wood (01:12:24.804)
If we're gonna get through these questions, we gotta go faster.
We discussed that. We can skip that.
Charles Max Wood (01:12:36.429)
Yes, and you can Google my blog post if you want to hear the whole tirade.
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.
We hit that one, yeah. Meta framework if you need SEO and fast initial page load.
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.
up to the level of other solutions that are out there.
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.
dry humor anyway. So the mental model, the async await versus go routines. Does that change how you think about concurrency?
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.
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.
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?
Ha ha ha! Uh... Because we have three minutes left? No, not really.
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.
Charles Max Wood (01:16:53.089)
It's also a nightmare in rails.
Charles Max Wood (01:17:03.968)
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?
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.
And that was back-end banter, not back-end dancer, right? Because it definitely sounded like he said dancer.
Charles Max Wood (01:17:50.585)
I was so on the dancer train, let me tell ya.
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?
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.
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.
That's a new verb?
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.
Thanks so much, yeah.
Talk to you guys later. It was great hanging out and jabbering.
Yeah, great conversation. Thank you.
Charles Max Wood (01:19:26.509)
All right, Steve, do you have some picks for us?
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.
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.
Right? And then finally, what do you get when you cross a dolphin with a lion fired from the zoo?
Give me a chance to wake up, sweetheart.
Nice. Where did that come from?
Charles Max Wood (01:21:04.492)
All right, Dan.
What are your picks? I don't know.
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.
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)
It's supposed to be a real funny episode.
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)
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?
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,
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.
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.
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.
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.
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.
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.
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.
Charles Max Wood (01:35:31.768)
Thanks for sticking around for a little extra. Oh, what do you have, Dan?
No, no, sorry.
Charles Max Wood (01:35:40.94)
All right, well, we'll wrap it up. Until next time, folks, Max out.
Bye. What I wanted to ask Chuck, and this can be asked post upload is, I'm just curious when you're listening.