AJ, Chuck, and Dan join this week's panelist episode. They dive into the resurgence of RPC (Remote Procedure Call) in JavaScript frameworks and the potential benefits and drawbacks of combining front-end and back-end code. They navigate the complexities and possibilities of modern development practices.

CHARLES MAX_WOOD: Hey everybody, welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS:  Hello from a very clear and cold Portland area. 

CHARLES MAX_WOOD: AJ O'Neill.

AJ_O’NEAL: Yo, yo, yo, coming at you live from... 

STEVE_EDWARDS:  The purple room. 

AJ_O’NEAL: It's pumpkin time. 

STEVE_EDWARDS: Do you need to change your color there from the purple? Maybe you need to get some orange.

AJ_O’NEAL: Yeah, but then I'd have to either get Wi-Fi lights or I'd have to go toggle it. And then I'd have to remember what the values are. I've left it this way for like a year. I haven't even turned them off. 

STEVE_EDWARDS: Oh, nice. 

AJ_O’NEAL: Like they're like five watt lights. 

CHARLES MAX_WOOD: So we also have Dan Shapiro. 

DAN_SHAPPIR: Hi, coming to you from my son's room, the Tel Aviv at war, Israel at war. Hopefully no sirens while we're recording. 

CHARLES MAX_WOOD: Right.

DAN_SHAPPIR: On the other, on the plus side, at least we have great weather. I mean, I'm wearing a t-shirt and the windows open. 

CHARLES MAX_WOOD: Oh, sure. Rub it in. I'm Charles Maxwood from top end devs. Um, I'm going to be releasing, uh, updated look and feel and functionality and new content to top end devs this week. So keep an eye out for that. Um, and yeah. 

 

Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to date their resume and find a better job. And I figure, well, why not just share my resume? So if you go to topendevs.com slash resume, enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing, through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume will get you that. And you can just kind of use the formatting. It comes in Word and Pages. formats and you can just fill it in from there.

CHARLES MAX_WOOD: So let's dive in and talk about this. Now, Dan, you recommended, I can't think of the right word, but it means recommended. So you proposed this idea for us to talk about, so I remembered the word. Do you wanna give us a quick intro as to what you're thinking, and then we can kind of jump off from there? 

DAN_SHAPPIR: Yeah, sure. So I'd actually like to start with a tweet that happened a few days ago on you know, relative to when we're recording on October 26th. It was a tweet by Adam Rakesh from a presentation at NodeConf. So you know, NodeConf happened also a few days ago. And one of the code snippets that they showed on screen demonstrated inline server action. So, you know, obviously describing code in a podcast is a challenge, but I'll try. Basically they had a form with a button and the form action for this form that was activated by clicking the button called a function that had use server in it. And that function contained an explicit SQL statement. So they use the,, a template literal, which means you've got the back ticks and also the word SQL in front, which marks it as an X SQL expression embedded in a string. 

AJ_O’NEAL: Which is just a function, by the way, a lot of people know this, you just find a function with a particular signature that is basically like string and then list of dollar sign things.

DAN_SHAPPIR: Yes. 

AJ_O’NEAL: And then you can use it with backticks. I guess you could use any function with backticks. Most of them would just throw an exception because it'd be the wrong arguments. 

DAN_SHAPPIR: Yeah, that's more or less true. It's a syntax thing. But basically, what they showed really was that even though that function was written inline in code that, well, obviously runs on the client side in the browser because it's a form submission attached to a button. the actual code of the function runs on the server side where it executes that SQL. So it kind of interleaved client side code with server side code. And of course everybody went batshit about it because, you know, PHP and, you know, separation of concerns and stuff like that. So yeah. So there was a lot of. Twitter chatter or X chatter around this whole thing. And Adam Rackes joke that they basically killed notifications for him because he was mentioned so many times that he just couldn't handle it.

CHARLES MAX_WOOD: Okay. Yeah.

DAN_SHAPPIR: But what was interesting for me in this whole thing, and I'll put aside this whole question of whether it makes sense to interleave client side and server side code. In the same file in this way and that's kind of its own discussion that you know we can have as well But I wanted to discuss a different aspect of this and that's the fact that Server side code is invoked by the by client side code As a function which means you're calling a function across the wire. It looks like a regular function call, well in this case actually a regular event handler, but it's still it's a function on the server being invoked from the client using function call semantics. And turns out that there's a name for this for this thing and It's this approach of invoking remote code across the network as if it was a function or procedure that you're calling locally. Are you familiar with this concept? Have you encountered it yourselves? 

AJ_O’NEAL: Well, I remember the UVU library used to operate on RPC in store state and cookies. And so you couldn't hyperlink to anything. If you gave someone a link, it would go to an invalid page. And the Utah business entity search does something really similar. So if you go to Utah business entity search and you search for a company and you find the registration, you cannot link to it to send it to someone else. So that's my experience with RPC is. Stateful, uh, server, server handles state, and you can't functionally use the web application, but I know that's not the way that it is with these APIs. Necessary. doesn't have to be that way. 

DAN_SHAPPIR: Yeah, it doesn't have to be. It can be. By the way, you know, we hopefully get to it. There are upsides and downsides to using this approach. And indeed, one of the potential downsides is that if you're not careful, you're creating end points that are difficult to use. Okay, so the interesting thing about RPC is that it's not a new approach. In fact, it's an old one. So therefore it's really funny to me that it's suddenly making such a huge comeback in the context of the web and specifically in the context of JavaScript frameworks in this last year. So like I mentioned, we're now seeing it front and center in Next.js. It was one of the big things that they were showing at NextConf. It's called... server actions, sometimes server functions, but I think they mostly refer to it as server actions. It's also available in QUIC with server dollar. And QUIC either actually took their inspiration from SOLID or maybe it's the other way around, but they also have server dollar. So in both QUIC and SOLID, you can actually wrap what looks like a local function inside server dollar. call it using function call semantics, but it runs on the server side. Its code is never downloaded to the client, and it's totally run on the server side. The parameters to that function are sent over the wire. The return, the result is sent back over the wire. So from the client's perspective, it looks like a regular function call, but again, it's actually executing remotely.

AJ_O’NEAL: So it looks like PHP, but it's transpiled into an RPC where what looks like a function is being turned into arguments, like basically being turned into JSON. So when you click the button, the function is transpiled to the server and the arguments that are sent into the function are being sent via JSON over the wire.

DAN_SHAPPIR:It could be custom could be anything else, but probably Yeah, the code splitting is actually done by the bundler not at runtime So at real time it actually even though it's like coming from one file potentially like that example from from next JS It's actually the bundler actually splits it into two separate bundles one bundle that can't be delivered to the client and another bundle that only runs on the server. And like you said, the function call actually translates into this process of serializing the arguments into some network protocol, probably JSON, sending them over the wire, deserializing them on the server side, handing them over to the function. The function executes the code and then You serialize the return value and send it back down. By the way, the old term, and I'll touch on why there is an old term used to be marshaling that instead of serializing, we would say that the, the, the, you know, in this particular instance of serialization and deserialization was called Marshall 

AJ_O’NEAL: go still calls it that in their modern APIs. I thought it was just like a language thing. Like some people prefer the term marshalling and some prefer the term serialization. But is it a nuanced thing like function versus method?

DAN_SHAPPIR:  I think it's a nuanced thing about marshalling being a special case of serialization because you know, serialization might be that you're serializing stuff in order to store it in on disk or in a database. And marshalling is specifically in the context of RPC and function calls over the wire. So it's a special case of serialization, deserialization. 

AJ_O’NEAL: Well, as, as you could suspect. This worries me strongly. This feels like we're, you know, we're again, plunging into the toilet. And I'll tell you why. Because I had my first experience. Well, no, I've had two experiences with server side rendering now, and both of them have been atrocious because it's developers who are newbie developers or that are just they're not familiar with the HTTP HTTP stack. They might not be newbie, but there's plenty of expert react developers that don't know how an HTTP adder works, right? 

DAN_SHAPPIR: There are plenty of react developers who don't know how the DOM works. 

AJ_O’NEAL: Yes, yes, exactly. So there's like fundamental basic things like 101 type things that people who might have five years experience have never learned. So one experience was with a cryptocurrency project. they are doing server-side rendering. And as you may be aware, traditionally, there are two different APIs for crypto. There's Web Crypto for browsers, and then there's Node Crypto for node. Now everything is switched over to Web Crypto for browsers is implemented by node and bun and all the others, right? So now everywhere, you know, and WinterCG has taken that even further and is adding like cross compatible support for... you know, promise objects and different APIs and all that. So like things are actually kind of looking good in terms of things that should have been in the standard library in the first place, actually making it into the standard library as much as we can call it that, but because this thing was server side rendered and it wants to know, Oh, is this, you know, is this browser code or is this node code? And then, you know, you're trying to like tag a certain file is it just, it just made it really complicated. It made it nearly impossible to use a hashing function in web crypto and node because it kept on wanting to like retranspile it for web crypto, for node, for the browser, right? So it's, and, and so, and it's like, it was, I think it was on netlify like their edge, whatever. So it's extremely new. And, and so it required. It required a specific version of node. Like you had to use 18, but you couldn't use 20 and you couldn't use 16 or something like that because of this module stuff. So there was that, there was that experience and we got it figured out. And the way that we solved the problem, I kid you not, was we switched a switch case statement to an if statement. And the reason was that when the transpiler ran when it transpiled the switch statement, it would put it in a, like it would, it would do a weird thing with function scope, probably for like the let versus bar or whatever. And when it did that weird thing, it triggered some other, you know, scope context and so it was just, it was weird, but the way we solve the problem to get web crypto to work in node in a server side rendered framework.was to not use a switch statement, but used an if statement instead. I'm not making this up. The PR to fix it was to switch that. So that's one. 

DAN_SHAPPIR: Yeah, just a comment on that though. I'm not surprised because this stuff is bleeding edge. First of all, I do want to mention that RPC in this context is not specifically connected to SSR. You know, there is the thing about JavaScript that's running server side and client side and both sides and whatever, but it's not directly related to that, but it is definitely related to the fact that the bundler slash transpiler needs to do a lot of magic to get this thing to actually work. And it's all brand new and bleeding edge. And I'm sure everybody's going to be running into a whole lot of issues like that, at least in the short.

AJ_O’NEAL: So here's the long-term thing I'm worried about, which is my next experience with this stuff. And again, it's not specifically RPC, but it doesn't matter because it's the same thing, right? Like whether you transpile it, or whether it's run directly on the server and then rendered, it's that the whole point is that you're mixing server and client logic in a way that they can't be untangled anymore. So somebody had created an Olamaclient web UI that's actually pretty good. And it, Olamma is local chat, GBT. I'm actually going to throw that in the picks, but they created a client for it and it had a dependency on node for no reason other than that. It was calling, it was making, it was doing fetch in node that could have been done in the browser so that the fetch was being handled server side. And so then I, I ask, okay, well, how do you build this statically? Cause I just want to put it in a web server, right? Like there's no reason that I should have the dependency of node and, you know, all this other stuff, because the way that people were interacting with this thing is, you know, like issues are about how do I do this in Docker compose it's like, Oh my goodness. Like all we need to do is take the static files and put them in a public directory. You do not need doc. This is not a Docker compose problem. Having having a website, make an API request to an API is not a Docker compose problem. But in this case, it became a Docker composed problem because it was using SSR. And the RPC thing is the exact same problem because it bundles a need for a server to do something that could have been done on the client through a normal API and not require that the UI layer, because now the front end, we're creating front ends that require a backend, not that use a backend because it's still gonna have to use a backend. But now it requires a back end just to load the front end.

DAN_SHAPPIR: I agree. But you do need to think about it also as simply another different way of invoking back end services. Now, if you don't need the back end service at all, then just do everything client side. There is nothing preventing you from doing that. 

AJ_O’NEAL:Of course not. But now that it's cool, 

STEVE_EDWARDS: people are going to do it regardless. 

DAN_SHAPPIR: Yeah, but I'm actually thinking, forget the coolness. It does create a tight coupling that's kind of avoided by other approaches like RESTful APIs. But before we get to that, I want to touch a little bit. I wanted to, one of the things that, one of the benefits of being more, let's say, experienced, or put another way, old in the industry is that you see all these trends, you know, come and go and then come and go again. And I'm old enough to remember the last time that RPC was really popular and it kind of caused me to start thinking about why it went away and why it's now coming back. What's what's driving this resurgence or comeback of RPC. So first I want to touch briefly on, you know, the previous iteration of RPC. which happened, you see RPC was really popular back in the 90s and not in the context of web at all. It kind of predated the web in a lot of ways. It was for basically, you know, you would write client server type thick applications, a Windows client talking to some Windows server or something like that. And they would talk to each other they would need to talk to each other. So, you know, there were various ways in which they could communicate. And one of the more popular ways was RPC. So first of all, first there was this, um, Oh, uh, kind of open source standard thing called Corba, which stands. 

CHARLES MAX_WOOD: Now I feel old. I never wrote Corba code, but I've heard. 

DAN_SHAPPIR: Yeah. Common object requests, broker architecture, you know, 

STEVE_EDWARDS:wow. 

DAN_SHAPPIR: You got to love it when there's the word architecture in the actual name. Um, it was this kind of a standard thing. It was fairly complicated, complex and heavy started way back in 91. Um, and it was really object oriented because object oriented was becoming a really big thing back then. And one of the key things about it was that it, it supported RPC and it was kind of language agnostic. So you could use it from any programming language. So it kind of had to define procedure or function interfaces using this kind of an interface definition language, which was language agnostic. So not only could you call it across the wire or the network, you could call, let's say, a C++ function from Java code or Ruby function from Python code and so on and so forth. Then Microsoft obviously invented their own flavor of RPC because why go with everybody else's solution? And theirs was known as DCOM or distributed COM. COM was the way that there was a protocol that or interface that Microsoft created for separately compiled components to talk to each other. It was again kind of object oriented and stuff. And DCOM extended that to be able to communicate over the wire. And then basically, and these approaches were really popular and they were really popular for a reason because as a developer, it's really attractive to be able to invoke remote services like function calls. that you don't need to think about network stuff. You just call a function. You're blocked until it finishes because that's how functions work. And then when it's done, you get back the return value. And if there's a failure, it throws an exception, something like that. So it's really attractive in this regard. And it gained a lot of popularity and then it basically died. And the reason it died was because of the web. Because when the web came along, all this stuff just didn't work with web browsers. There were two main issues. First of all, this stuff just didn't work with web browsers. You couldn't do an RPC call from within a web browser. And the other issue was that when the web happened, the sysadmins basically closed off all the ports except for the web port so basically you had port 80 and what's the SSL port? I always forget.

CHARLES MAX_WOOD: 443. 

DAN_SHAPPIR: And basically those, to begin with, it was even just port 80 before we got SSL. So basically all the ports were closed. And these RPC implementations were all built on using, doing UDP stuff over custom ports and stuff like that. So they just didn't work anymore. They were all blocked. And good luck getting your IT guy to open the port, you know, all the ports for you because your RPC implementation does an automatic port selection that you have no control over. Yeah. So, you know, all of us switched over from using this stuff to using other types of protocols like RESTful APIs, sending JSON over HTTP, doing the serialization manually, or maybe sending form data, stuff like that. And you know, I'm trying to, I think it was this, you know, Dan Box, Don Box was a really popular speaker back then and he used, he joked that we picked all these protocols because the sys admins configured it so that only porn could actually go to the firewall. So we had to masquerade our APIs as porn. Uh, yeah. So that killed RPC for a really long time. Uh, and nobody would, you know, I. I didn't, I haven't thought about it in years. And then all of a sudden I'm seeing it everywhere and I'm thinking of, you know, what changed now obvious. So first of all, it turns out that there was some RPC stuff being done, but it was mostly done server side, uh, turns out that for example, Google introduced this thing called the gRPC It's an open source project which actually uses HTTP to as its transport protocol But in a way that's actually not compatible with web browsers. So they actually if you wanted to do 

AJ_O’NEAL: that's important 

DAN_SHAPPIR: Yeah, so that it turns out that if you actually wanted to do gRPC from the browser you actually had to had used some sort of a gateway server. So you downloaded the special client that communicated with the gateway server over like regular HTTP2 that browser support, and that would actually translate it back and forth for you. Obviously that meant that the gRPC was much more of a backend type technology than one that would be used with the front end. Then along came TRPC, which a lot of people confused with gRPC because the name was kind of similar, but it really has nothing to do with it. And TRPC was a library that kind of reintroduced the concept of RPC into the browser. It allowed you to write to import this library and then make calls across the wire in a way again that looked like function calls. Now, why did this happen? And I think that two things kind of enabled it. And it's, by the way, I have to say that this is totally my own personal take. Others might disagree. And if you have, like if our listeners have a different point of view, I'd be really happy to hear about it. So feel free to reach out to me on, on X or whatever. Um, but I think that two things drove it and these two things are a sync await and TypeScript.

CHARLES MAX_WOOD: Yeah, I have to say, like, I was mostly working in IT back when a lot of the stuff that you were talking about, Dan, were things. And so I just see the errors in different apps, right, in different logs that I was on machines I was working on and, you know, would kind of elevate those to the different people who were supporting those applications. And so they were writing things that use gRPC or RPC uh, calls way back in the day. I hadn't ever heard of TRPC until probably a month or so ago. And then I just haven't had time to really dive in. And so, yeah, I'm, I'm, that's where I'm curious is like, okay, you know, who's using this and, you know, why are they picking this up now? Because yeah, I kind of agree with AJ at this point, and it might just be out of, you know, not having looked at TRPC to really understand what the upside is. But you know, rest works pretty good on most of the apps I use. 

DAN_SHAPPIR: So again, it's this whole idea of making, of invoking remote code, effectively in this case, it's server code from the client side in a way that looks like a function call. And that's why I'm saying that the catalyst, that kind of brought this along or the two catalysts are TypeScript and Async-A-Wait. And I'll start with why I think, which one, you know what, I'll leave it up to you. Which one would you like me to explain first why I think it's a catalyst, TypeScript or Async-A-Wait?

AJ_O’NEAL: It's Async-A-Wait because TypeScript seems obvious. 

DAN_SHAPPIR:Okay. 

AJ_O’NEAL: It's types. 

DAN_SHAPPIR: Yeah, you know what, so we'll do the opposite of what you said because, you know, it's obvious to you but it might not be obvious to others.

 

28:59

CAHRLES: Um, rebel. 

DAN_SHAPPIR: So, so, oh yeah. Like you said types because. You know, JavaScript being untyped means that, you know, you're, you're passing parameters in to a function or getting a return value. It might literally be anything. And you get into all this duck typing thing and, and, you know, or having all sorts of ifs, uh, checking types of things. And It's really in that regard, no better than using JSON. You might as well pass in an object containing everything and just go through the properties and figure out what you got. So in the pre-statically typed days, sending a JSON, doing a remote invocation as a function call has no real advantage over uh, just sending JSON because either way you don't really know, you know, what the types of the arguments that you're passing are. So they're just a collection of things. And likewise with the return value. Once you TypeScript happens and you know, you've got this smart transpilation and bundler stuff that we were talking about before, then with RPC. When you're invoking that code as if it was a function, it also means that the TypeScript type checker can verify that you're passing the correct types of things over the wire from the client to the server, from the browser to the backend, and you're getting back as a return value what you expected to get back. So for example, I could implement an add function on the server side and make sure that I'm passing in two numbers and getting back a number. And the type checker validates this. And this was not relevant prior to TypeScript. So there was much less motivation of using this kind of an approach or this type of protocols. So. typing, static typing that's been brought in to front end development. Thanks to TypeScript is a huge catalyst from my perspective into why RPC has become attractive again. Or like, are you on the, do you agree with me? Do you think it makes sense? 

DAN_SHAPPIR: It's obvious that you would want to do it in TypeScript. It's not to me. It feels like now that we can, we must. Rather than Like, yes, it makes sense that there's a resurgence. I'm not bought into the idea that this is better than the alternative. Just that, well, now it's possible. So now someone will do it.

DAN_SHAPPIR: Because again, if you're doing restful APIs and you're passing JSON, once that data becomes a JSON, you're kind of, you kind of lost the type information. It's up to you at runtime to validate the stuff when you're doing it everything in the context, let's say of the same Next.js project or even Next.js file, then TypeScript does this validation for you at build time. 

AJ_O’NEAL: I understand what you're saying. I don't like go validates that it built time.

DAN_SHAPPIR: Yeah. But go is that the key type. 

AJ_O’NEAL: Well, right. But that's it's tooling. Right. So..

DAN_SHAPPIR: you end of the day,

AJ_O’NEAL: it's just tooling. 

DAN_SHAPPIR: Yeah.

STEVE_EDWARDS: I do things for tooling too. Right. Even in Ruby or JavaScript that aren't right. Because it, it makes my life easier. 

AJ_O’NEAL: Yeah.

DAN_SHAPPIR: So now I'll touch on the second point of a sinker weight. And for that, I'll start it the way that Chuck likes these sort of things with a story. So a long time ago, I was working with this guy who was a hardcore back end developer working Java, C++, stuff like that. And then he decided to do a front end project. And one day, so he starts coding JavaScript in the browser. That was pre TypeScript days. And one day he comes to me and he asks, how do I block on a network call? And I'm going like, say what? And he says. I have code JavaScript code on the client that calls the back end service. I you know I have nothing to do until I get the results back. How do I write the code that blocks on it until the result comes back? And I said. You don't because he was used to the multi-threaded backend world where you invoked an API, the thread was blocked, and when the result got back, the thread was unblocked. And things continued to work because you had other threads. And obviously, no, that's not the way that browsers work. Now you might be a stickler and say, yeah, you can make a blocking Ajax call, but you really don't or you really shouldn't. It's a hack and it's deprecated. These days we also kind of have workers where you can do these blocking calls, but really if you're working, like you usually do certainly back then, you don't want to block on a network call. So instead, you do what we do. You have...You know, it used to be you had a call back then. The answer was you use the call back. You made the call. You had the call back in a closure. Uh, you gave back control to the, you know, to the event loop. And when the value got back, you, uh, you know, the call back happened and it had access to the context because of the closure. And that's the thing that I kind of had to explain to that developer. And you know, he had to wrap his mind around it. I think that he wrapped around his mind around it to such an extent that after that project was done, he immediately went back to doing back end development and never did front end again. But so, and that was one of the problems with RPC, because with RPC, you invoke code across the wire like a function call. It means that it kind of needs to be blocking and you're not supposed to continue until that function finishes, because when you call a local function, you know, you only get back control when that function is done. So blocking is kind of inherent to this whole RPC model, and you know, you really couldn't do it, or couldn't do it well in the browser. And then we got a sync await. And with a sync await, you can make it look close enough to blocking. That remote function, it returns the local proxy for that remote function, the thing that serializes all the parameters and actually makes the network request, that returns a promise. and that promise results with that remote functions return value. So you can await on that promise, and then your code looks as if it's making this synchronous function code. So going back to what you said AJ before, it's just tooling, it's just syntax. But the whole idea of RPC is this whole. Syntax slash tooling thing that remote stuff looks and feels like local stuff and and a sync-a-wait kind of enabled it So from my perspective those were the key Quote-unquote breakthroughs that kind of made RPC Attractive again There's actually a third thing but before I touch on that You know do you have anything to say about this? And you know, how are we for time?

 

 Hey, have you heard about our book club? I keep hearing from people who have heard about the book club. I'd love to see you there this month. We are talking about Docker deep dive. That's the book we're reading. It's by Nigel Poulsen. And, uh, we're going to be talking about all things Docker, just how it works, how to set it up on your machine, how to go about taking advantage of all the things that offers and, uh, using it as a dev tool to make sure that what you're running in production mirrors what you're running on your machine. And it's just one of those tools a lot of people use. They're really looking forward to diving into it. That's February and March, April and May, we're going to be doing the Pragmatic Programmer, and we're going to be talking about all of the kinds of things that you should be doing in order to further your career according to that book. Now, of course, I have my own methodology for these kinds of things, but we're going to be able to dovetail a lot of them because a lot of the ideas really mesh really nicely. So if you're looking for ways to advance your career, You're looking to learn some skills that are going to get you ahead in your career. Then definitely come join the book club. You can sign up at topendevs.com slash book club.

 

AJ_O’NEAL: That's really interesting. Like I, I, yeah, I, I agree now. Now I understand why. And that's why we get a tweet that looks like PHP, but trans like effectively it's PHP effectively it's run this function, a server run this function. But it's actually transphot piled and doing RPC. So it's, it's interesting. It's like. Even I can appreciate the coolness of it. Like, oh, that's a tricksy thing to do. I just don't think it should be done. It should be obvious, not hidden behind layers of. 

DAN_SHAPPIR: Look, it seems that server actions or server functions are going to be the preferred way for Next.js for client side code to invoke backend services. So get used to it. You're going to be seeing a lot of it.

AJ_O’NEAL: I'm not, I'm not. Ha, ha, ha. 

DAN_SHAPPIR: Because you don't use Next.js. But frontend developers are going to be using it a whole lot. That's what I'm saying. And like I said, it's not even only Next.js, it's also Redwood.js in the React world, eventually probably Remix, even though they're making sounds about not really liking this pattern. I'm guessing that unless remix decides to ditch react at some point, they eventually might not really have a choice. Also, like I said, it's built into solid, it's built into quick. So it's, you know, it's going to be popular all over. And that's kind of it.

AJ_O’NEAL: It's good to spread our bugs across the place where traditionally back in people handled them and we're front and people handle them. We want bugs. We want as many weak links in the chain as we can as many multiple points of failure as we can because it really sucks when apps work. Nobody gets paid overtime when apps are working.

DAN_SHAPPIR: Well that's the thing if you're looking at these and that's the third point that I kind of wanted to mention about this whole thing is that it's all tied to this thing this whole meta framework thing that the framework makers have decided to make all of us full stack. So when you write in Next.js, I think that it's Theo that said it, that Next.js is a backend framework, not a frontend framework. Even though it's built on React, so you're kind of conditioned to think about it as a frontend thing, it's actually a backend thing. And we've got cats and dogs here, obviously. Hopefully you're not hearing them. 

CHARLES MAX_WOOD: We hear them, it's fine.

AJ_O’NEAL: It's it's fame.

DAN_SHAPPIR: OK, you know my cat, my dog doesn't like the cats that are outside. Anyway. So the frameworks are now becoming meta frameworks and are striving to handle both the front end and the back end as a single unified application. And that means that, you know, the two sides need to communicate with each other and they're bringing in this whole RPC mechanism as a really nice way from their perspective to tie the backend to the front end. And when people start bugging them about separation of concerns, I think it was like the React. uh... the react uh... ctl uh... forget uh... his name who responded to to this uh... to to these complaints about this whole lack of separation of concerns any basically his perspective is you know these are functions that are running in the context of the same components on simply breaking a component's functionality on on that some of the functionality runs the server side and some of the functionality runs on the client side. So there shouldn't be a separation of concern because it's the same component. It just parts of it live in different places.

STEVE_EDWARDS: Again, in other words, he wasn't concerned about it.

DAN_SHAPPIR: Exactly.

STEVE_EDWARDS: I missed my drum rim shot. I need my rim shot. 

DAN_SHAPPIR: Yeah. Figure out how to add it here. 

CHARLES MAX_WOOD: We'll figure it out. 

DAN_SHAPPIR: Yeah. So anyway, again, so you're really seeing this thing take shape Or you know, come to the forefront as in the context of all these meta frameworks, transforming all of us from being, you know, either front end engineers or back end engineers to being all of us full stack engineers, at least for the, you know, smaller projects, because again, some of the components functionality runs on the client side, some of the server side, you know, if you think about react server components, these are components that run on the server side. but are displayed on the client side. So again, this whole blurring, intentional blurring of the distinction between writing code for the front end and writing code for the back end.

STEVE_EDWARDS: So you were talking about how you're including server calls with the, I think the example was the dollar something, sorry, I don't forget, I don't remember the exact syntax and you're including it. Does it, I mean, do you have to...have to include it within your front end calls? In other words, can you make a call out to another function that in turn calls your RPC? I mean, the thing that comes to mind is, you know, AJ's favorite language, PHP. And, you know, when it first came out, you with the beauty of it is or the danger of it, depending on how you look at it, is in a PHP file, you could combine your HTML and your PHP code, right? You could loop through stuff in PHP and then spit out your HTML. And that became a concern because you weren't separating concerns. And so you've got templating languages where you, you pass in your values and just your HTML and so on. So I'm wondering, I guess one thing I don't understand Dan is if you're doing your RPC calls, do you have to do them from within your front end or can you wrap them in a separate function that you call from somewhere else? Not being familiar with React, I can't really, you know. I'm not familiar with it. You understand what I'm asking? 

DAN_SHAPPIR: You kinda, I think it's more a question of, you're asking not from the front end, but from within the component. Because the whole idea of RPC is to call it across the wire. So it's either you're calling it from the front end to the back end or from one backend service to a different backend service. Now. between backend services, you know, we talked about the fact that you don't need this whole thing, you can use stuff like gRPC because you're not limited by what browsers allow you to do. So, you know, you can do all sorts of funky stuff because it's server-side code. So you really, so this whole RPC quote unquote revolution  is in the context of being able to call from front end to the back end. Um, now the front end, it, you know, usually in the context of a react, it usually originates in a component, but assume that you can call the component can call another local function or maybe it has to be a hook or something, but at the end of the day, it's a function and that function can call the backend function as using that RPC mechanism. Now, the thing that was kind of, that got everybody's attention in that example from NodeConf is that the code was interleaved inside the single file. That's kind of... 

STEVE_EDWARDS: A code spell, isn't it?

DAN_SHAPPIR: Yeah, but again, it has to do with the fact that from their perspective, all this functionality, whether it's running in the client, whether it's running on the server, belongs, quote unquote, to the same component. So why shouldn't it be in the same file? Now actually React previously required it to be separate. So quick and solid allowed it to be in the same file whatever you wanted to run remotely inside the server dollar. But you could have it all in the same file, whereas React actually previously required to put those server functions in a separate file with this use server at the top as a way to indicate that. Now, they allow it to be inline. So they're achieve parity with what Quick and Solid could do before. But that's your decision, whether you want it in the same file or a separate file. Either way, it's still RPC.

STEVE_EDWARDS: I guess I just tend to be pretty, from a code standpoint, I tend to be pretty structured, and I try to keep things separate. I was guilty when PHP I used to combine the HTML and the PHP on one file. And when I was first learning it, then I got more knowledgeable, more experienced to have what you want to say. So I was just trying to wrap how this is combining things like that and not being a bad thing. 

DAN_SHAPPIR: But I'll say this. So I like you. I like to keep my files small and concerns separate. And I was speaking to Ryan Corneato, the creator of Solid, who we've had as the guest multiple times. And I asked him, like, because he introduced this whole server dollar thing, and I asked him, like, what's the benefit of being able to put both the backend stuff and the frontend stuff in the same file? And it turns out that a lot of people, and Ryan apparently included, like to do simple things as one huge file. So they write this project that's like one big file and then they start breaking it up if and when it gets out of hand. But a lot of their simpler projects they just do as a one file.

AJ_O’NEAL: So I get that, I like that, right? Like typically my thought is a JavaScript library should be one file. It should not be one file per function. It should just be one file, if your library doesn't fit in a file, it's not a library. It's a framework or it's an application or it's something else. Um, but there's this, the social contagion is what I'm most worried about is people doing dumb things, thinking that it's cool and doing worse than if they had done the really stupid, simple thing, the kiss thing, right? So.. On the one hand, all these frameworks are going to tout their benchmarks. On the other hand, these people who are creating the frameworks are going to say, Oh, look how simple this is. You just throw it all in one file. And those two things are diametrically opposed, right? Like the place where you care about benchmarks and how this one's faster and has better scores on Lighthouse is diametrically opposed to this is so small and unimportant that we can fit it in a single file.

DAN_SHAPPIR: Yeah, but not exactly because the whole thing is that the bundler kind of. It's like a compiler and linker. It's, it's, you kind of, uh, um, the, the fact that it, the source code is written in one file doesn't mean that it's ultimately shipped as one file, the bundler, at the very least breaks it into some,

AJ_O’NEAL: no, no, what I mean, what I'm, I'm not talking about, I, I, sorry, finish. I get what you're saying, but finish.

DAN_SHAPPIR: Yeah. I'm saying that the bundler breaks it at least into two parts the code that runs on the server and the code that runs on the client and probably build breaks the client side part into even smaller parts in order to be able to ship only the stuff that's actually needed on demand and so on and so forth. So you write everything is this one huge thing, but the bundler is really smart about breaking it up for you. You know, assuming it does the right thing. 

AJ_O’NEAL: That makes it worse to me because now it's over engineered for something that fits in a file, right? But my concern is not, oh, the performance is gonna be worse. My concern is that developers are going to be writing worse code. Like if something scales to the point that you need every extra millisecond of performance, well, one, why are you using Node? But if it scales to the point where you need every millisecond of performance and you're writing everything in a single file, like you see what I'm saying? Like it's... If you start out on, there's this balance, right? On the one hand, there's the Singleton factory, factory class factory of the Java enterprise Hello World. And then, right, but at the same time, we really don't want people to start out with a boiler plate of a single file that's mixed, API calls and RPC calls and server calls and client rendering and CSS. Like one. Who is the person that can actually understand all of that? Cause you have to pick some technologies that you actually know well and the other ones you're going to suck at. You can't know all those things. Well, 

DAN_SHAPPIR: so I have to respond to that. So I was kind of, I did like a shit post or shit tweet in response to that thing where basically said that, you know, what's the difference between a front end developer and a backend developer, a backend developer is forced to learn SQL. and a front end developer is forced to learn CSS. And like you said-

AJ_O’NEAL: I think it would be the front end developers forced to learn JavaScript because their primary job is to do the CSS. 

DAN_SHAPPIR: Yeah, but now everybody does JavaScript or TypeScript, both the front end and the back end. Everything is TypeScript. So the difference really is whether or not you do TypeScript with CSS or you do TypeScript with SQL and the full stack is the, you know, got the toughest job, he has to learn both. But before we run out of time, I really quickly, probably we don't have time to cover it in depth, but I really quickly want to touch on a few drawbacks of this approach. I mean, we mentioned some, but I want to mention a few that seem to be kind of intrinsic to this approach. So one drawback is, I think, is a potential proliferation of endpoints. I mean, because it's so easy to create them. You know, you want to expose some data from the server to the client, you just create another RPC endpoint, another function, any component might have them. So it's, you know, and which kind of brings me to like the big change that we will probably be seeing that currently the number of APIs, the API endpoints usually tend to be fairly limited and well known and documented, hopefully, and structured. And you know, this whole restful API thing is all about how we structure our endpoints. And, and, you know, and now, you know, it's just going to be, Hey, I need some data. Okay. I'll create another function. It does whatever directly to the database gets whatever data I need and just expose it, you know, directly to the front end.

AJ_O’NEAL: Uh, you can auto generate documentation for that.

DAN_SHAPPIR:  And yeah, but.

AJ_O’NEAL: It'll probably be better than GraphQL documentation.

DAN_SHAPPIR: Yeah, but these functions are really ephemeral. They'll be coming and going. 

AJ_O’NEAL: Well, you auto-generate them,

DAN_SHAPPIR: you know, npm run build. Yeah, but that's the other thing. It will create this sort of a distinction for good and bad between internal APIs and external APIs. I think it, who was it, like Jeff Bezos, who wrote that famous email to all the Amazon employees that have all the components must communicate through well-documented public APIs, something like that. 

STEVE_EDWARDS: Uh-huh. Remember that. 

DAN_SHAPPIR: And here, you're going to have lots and lots of APIs that are wholly internal to your next application or your solid application or your quick application, and they're probably going to be completely distinct from the public APIs. So who's going to make sure that the public APIs still work because nobody internally actually uses them? 

AJ_O’NEAL: Maybe what this is building a use case for, and I think this might be where it's headed, is a meta WordPress. This isn't like building an application. This is like having a meta WordPress where you've got slushy APIs that you can add or remove anything to it will these components that just automate the plugin install process. Maybe that's what it kind of turns into is it's like a slushy WordPress type of thing, but where you have full control over the UI layer rather than being constrained in the plugin architecture that WordPress has.

DAN_SHAPPIR: Possibly. What I'm really concerned about is a world where, you know, the, This is really expedient and it makes upfront development really fast, but then you're left with a tangled web or, you know, ball of string that's going to be really difficult to unravel and a lot of tight coupling between front end and back end that you're going to have a really terrible problem fixing if and when you need to make certain changes, which brings me to another problem which is versioning and public APIs. Theoretically, you could make those endpoints public. I think that all of these vendors. 

AJ_O’NEAL: You make the component public, not the API.

DAN_SHAPPIR: No, you can actually theoretically make, like if you publicize how you serialize the stuff over the wire, then you can make the endpoint public.

AJ_O’NEAL: But that seems counter to what the framework is doing, right? That's going around the framework, not using the framework.

DAN_SHAPPIR: I agree.

AJ_O’NEAL: If you're using the framework, you would publish the components. And again, I'm very apprehensive about that, but it's cool. Like it's a neat, tricksy thing to do. But you would just publish the components and the components are the API. 

DAN_SHAPPIR: Yeah. But again, if I'm creating an API and I do want, and I do have both, And I do want to have public APIs for my application, and I don't want to maintain a proliferation of APIs, and I want to make sure that they always, always probably all properly work. I may want to, but I also want to leverage all the benefits of invoking them as RPCs. It kind of needs to be able to work both ways. And I understand that in theory it can, time will tell how it actually works in practice. I'm concerned about that and the final thing that I'm really concerned about that I wanted to mention really briefly is versioning because if it looks like a function, function calls aren't versioned, uh, the way I remember from the, the decom days or the calm days, you would have do something, do something to do something three, do something for,

AJ_O’NEAL: I've seen that in rust code.

DAN_SHAPPIR: And yeah, so they are doing certain things for versioning inside the context of the application itself, maybe even reload the application, because think about it. Let's say I opened an application written in Next, and it has these RPC calls to the backend, and it's open on my computer for a while. I went out to lunch and while I was eating lunch, a new version was deployed on the back end. And then I come back and I'm trying to use the front end, which is an SPA, so it's still running. And it's making function calls to endpoints that no longer exist or maybe have a different signature. How is that handled? It's a good question. Now, when we use JSON over the wire,

We think about this sort of thing and we strive to make it backward compatible to some extent, you know, or we keep old endpoints. Here it's, you know, by kind of by definition, the old endpoint will be gone and either replace in place or some other place, you know, I don't know what will happen. It's so maybe you notice that and when you get an exception, you reload the page You know, I don't know. 

AJ_O’NEAL: I'm also worried about what happens when someone accidentally deletes you server and then expose their private keys to the internet. Cause that's, that's going to be happening. 

DAN_SHAPPIR: Yeah. The first of all, obviously that's going to be happening. Uh, they do have to be fair. They do have certain safeguards against it. So like if you put, um, uh, code in separate files, you can actually have an special like import that if you accidentally try to import into a client side file, it will break. So you have things that can help you guarantee that this file can only run on the server and won't ever be downloaded to the client because the build will break if you try to actually download it. But I'm sure that we're going to be seeing situations where just the fact that the same developer is writing server side code and client side code and it's not trivially clear where the code is actually executing is a recipe for this stuff to happen for sure. 

AJ_O’NEAL: I really wish our focus was more on how do we enable developers to fall into the pit of success 

STEVE_EDWARDS: instead of despair. 

AJ_O’NEAL: Yeah. But, but I mean, we're just, we're just people get bored and they spin the wheel again. It's like, oh, I haven't seen RPC in a long time. Ooh, what cool thing could we do now? But that's like, I wanna see people falling into the pit of success. I wanna see people who are undereducated, who are going through boot camps, who are working in their first job and have too much stress and load on them. I wanna see them falling into the pit of success and the pit of longevity, sustainable project. And..  I think it's obvious this is not that.

DAN_SHAPPIR: I'm not sure because to be fair, there are benefits to this approach, especially if you're building small to medium projects, if you're building one-offs. I can see a lot of benefits in that. The fact that you've got type safety. 

AJ_O’NEAL:Hello world, to-do app. 

DAN_SHAPPIR: The fact that you've got type safety over the network is really powerful. You know, we've seen, we've all encountered situations in which somebody got an improperly structured response, didn't fail on it and instead misinterpreted it. We've, we've all seen that sort of thing in, in, in web applications. 

AJ_O’NEAL: Well, you can't, but you, you can't rely, the tooling is for you as the developer. It doesn't provide you with security. I mean, if you, if somebody just wants to curl and Throw in a number where they're supposed to be a string. Hopefully you don't 500 and no, 

DAN_SHAPPIR: obviously, obviously I would validate things before writing stuff to the database, but, uh, and I, and I strive not, although again, if you know, not to crash the server, if somebody sends me in. Improperly, you know, improper values as parameters. And I assume the actual library layer provided by let's say, uh, Vercell in next JS safeguards against the, the sort of, you know, at least the trivial things. Um, but again, the fact that I'm, I'm sending, let's say a number and a string and it's enforced by the type checker to be a number and a string on both sides at build time, not at runtime at build time is pretty powerful and the RPC model, like I said, is very attractive. Oh, one more problem, potential problem with this type of thing that we saw a lot in the decom days. And I think that would more or less be where we finish is really chatty protocols. Because you, it all looks like function calls. So you make a lot of function calls and each function call is a round trip over the wire. So you wait on this and then you wait on that and then you wait on another thing.

AJ_O’NEAL: Well that's been hailed as a virtue with GraphQL, right? That's like the whole selling point. But seriously, that is the selling point is like only get what you need when you need it. So even though you know you're gonna need all these. 

DAN_SHAPPIR: Yeah, but I'm talking about something that's even, but I'm talking about something that's even worse. 

AJ_O’NEAL: Okay.

DAN_SHAPPIR: Something where let's say I need to, I know that I need to get these two values. But because of encapsulation, I write them as two separate getter functions, and I invoke both getter functions over the wire. So I ended, and they're both, they're not like promise all each one. It's his own a sink awaits. So I'm doing the first one to get the first value and then the second one to get the second value instead of having a single API call that gets both values.

AJ_O’NEAL: And, and, and the graph QL was better, better in that respect because you could, well, in, in, in theory, you could, I think the practice that ended up being about the same. 

DAN_SHAPPIR: Yeah. But, but what I'm saying is because network calls masquerade as function calls, you start thinking of them as function calls. 

AJ_O’NEAL: And then in local dev, it feels like that. Cause in local dev you've got zero millisecond response time. 

DAN_SHAPPIR: Exactly.

AJ_O’NEAL: and infinite bandwidth.

DAN_SHAPPIR: Exactly. And I'm worried about- 

CHARLES MAX_WOOD: Yeah, my conversations go fast when I'm talking to myself too. 

DAN_SHAPPIR: Yeah. So I'm really con, and in DCOM, the old DCOM RPC days, we definitely saw a whole lot of that. Really, you know, APIs that were built to be super chatty, that required a lot of back and forth to really do anything, because of encapsulation, because of separation of concerns, because you looked at everything as if it was a regular function with the costs associated with a regular function call, which are effectively zero. So yeah, so, and that more or less, I think, concludes our time and my thoughts on this topic. 

CHARLES MAX_WOOD: Yeah, it does kind of get us toward the end of time. Yeah, I look forward to some talks or things coming out from you on this.

DAN_SHAPPIR: Fingers crossed, I've submitted to a couple of conferences. Let's see who's willing to accept a speaker from Israel these days. 

CHARLES MAX_WOOD: Well. I would if I were running a conference. Anyway, all right, let's go ahead and do some picks.

 

Hey, this is Charles Maxwood. I just wanted to talk really briefly about the Top End Devs membership and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive. and we're gonna be going into Docker and how to use it and things like that. We also have workshops on the following topics and I'm just gonna dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job, but at the same time, they also want to make more money. And so we're gonna talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want. And having it support the lifestyle you want. That one's gonna be on February 7th, February 9th. We're gonna have a career freedom mastermind. Basically you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff. And then we're gonna actually brainstorm together. You and whoever else is there and I, all of us are gonna brainstorm on how you can get ahead. The next week on the 14th, we're gonna talk about how to grow from junior developer to senior developer, the kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're gonna do a Visual Studio or VS Code tips and tricks. On the 21st, we're gonna talk about how to build a software course. And on the 23rd, we're gonna talk about how to go freelance. And then finally, on February 28th, we're gonna talk about how to set up a YouTube channel. So those are the meetups that we're gonna have along with the book club. And I hope to see you there. That's going to be at topendevis.com slash sign up.

CHARLES MAX_WOOD: Um, I'm just going to go from top to bottom. So Steve, what are your picks? 

STEVE_EDWARDS: Uh, I came across an article, uh, we're going to see it two or three days ago, I think, and just to give a little background, um, one of my source spots still is, is how during COVID we isolated everybody behind zoom, where there was work, especially kids and the destruction that was right on them still pisses me off. But it was an interesting, um, article. It was a study that recently came out and I'm trying to find, uh, the URL here cause I wasn't prepared for it. Here it is. And it was about the difference in the brain that happens. It's a comparison between what happens when you have a conversation over zoom versus what you have, uh, what happens in person when you're actually sitting there talking to a person face to face as compared to over zoom over zoom. And the gist, the tagline from the study was the research suggests online faces with present technology don't engage our social neural circuits as effectively. One of the words, and this is common knowledge to anybody who's paid attention over the past few years, video conferencing, it's not the same as in person contact. You know, it's whether it's face to face, whether it's physical touch, whether, whatever it is about the way were made, the in-person contact is so much more important. You get so much more out of it than just a Zoom call. And there's the ongoing debates about working remotely versus working in the office. And that'll go on for a long time. There's pros and cons to either depending upon the situation. I was listening to another podcast, I believe it was this week, this morning, it was Syntax, and they were talking about how recently they had gotten together in person in the office and they said, one of the hosts said it was just crazy how much more they got done being in person and how much more energy there was, you know, how much was gained by being in person. And my company, we're all remote. And for the past few years, we've tried to get together in person at least twice a year. And my boss and I have both noticed how much more we get done meeting in person than being remote. So the study was It's a neuroscience news is the URL for the study. We'll put it in the show notes, but it's really fascinating. And to me, it just confirms, you know, other city studies along the same lines that have come out over the past few years. 

DAN_SHAPPIR: So I'd like to make a comment about that. So in Israel, like everywhere else, obviously with the COVID remote work became a really big thing. 

STEVE_EDWARDS: Same here for sure.

 

DAN_SHAPPIR: Yeah, and you know, because Israel is kind of small, so this, you know, there are traffic jams and whatnot, but still you can get from one place to another in Israel to another usually by an hour or two of driving. So in terms of distances, the whole concept of remote working is less relevant when you're working for Israeli companies. I mean, if you're working for an overseas company, obviously that's a different story. But with COVID, remote working became really a thing. And then when COVID kind of was over effectively, people, you know, a lot of companies were starting to like try to recall everybody to work back in the office days a week. And that's where we were for a while. And now with this war happening, everybody's working remote again, because everybody wants to be with their family and nobody wants to get caught on the road if there are like rockets falling and and stuff like that. So You know, you come to the office, the office is basically empty. Also schools were out for a while. There are now, you know, certain areas of the country, they still are. So, um, we are completely back to remote working all over again. Uh, so, so yeah, turns out you need a word for that. 

STEVE_EDWARDS: Yeah. I think between you and Ukraine, those tend to be more of the exception than the rule, you know, to be honest, but let me ask you this, Dan, do you?VYou know, having worked both in person and office, and I worked in office for, you know, probably 15 years, 19 years before I ever went remote. Do you notice a real difference between what's gained working in person versus remote in terms of interactivity team and productivity and so on?

DAN_SHAPPIR: Oh yeah, for sure. One of the things that I really like to do, which really is a big part of the type of work that I do is kind of a call it a walkabout, which is I literally like to walk around the office barge into people's offices assuming they're not in the zone or whatever, you know, you don't want to interrupt somebody who's, you know, typing away. But if I'm looking at somebody who doesn't seem to be really busy at that point in time, then I start asking them about what they're working about, working on, how they're implementing it, you know, what the issues that they have. I've even encountered situations where I found two people working on the same project without being aware of each other, simply by talking to them and listening to what they're working on. Or especially because the type of work that I do is really cross-cutting, I can provide feedback to people who are working on a lot of different types of things, or it's interesting for me to learn what they're working on, the problems, the challenges that they're encountering. And that's not really something you can do, at least not that I found when working remotely. On the other hand, there are advantages. The fact that you avoid the commute. I mean, if the commute is two hours a day is, you know, an hour each way, then you just, you know, save two hours a day. That's a lot of time. 

STEVE_EDWARDS: Yeah. I mean, you can, I remember my first remote job, we used to talk about that. How, if anything, you could maybe split the difference and that gives you a little more time to work, you know, if you can increase your productivity that way. You know, the things I miss is just being able to walk around the corner and say, Hey, what's up? You know, help me with this problem, then you get eyes on it or, you know, just sharing of ideas. And there's, like you said, I don't have to bring food into the office every day and get dressed up, you know, I'm notorious for my dressing up. I'm to, you know, I'm the kind of person that people ask me why I'm dressing up when I put on a shirt with buttons on it instead of a t-shirt or a sweatshirt. So, you know, for me, That's why you're in tech. It saves in my, right, it saves on my wardrobe. So there's pros and cons to every situation. My point of the study though, is just that I'm hoping people were realizing that there's a, We are social people. You know, we have to be that in-person contact is really important, not only to work, just relationships and functionality as a whole. 

DAN_SHAPPIR: I've heard of companies where remote working was really a big part of the culture and they had various tricks to get around this sort of thing. So for example, a team of people working remotely would basically like launch Zoom or something like a group Zoom at the beginning of the day and just keep it open, even though they weren't really, you know, working together. But it's still not the same thing.

STEVE_EDWARDS: You're right. It's not. 

CHARLES MAX_WOOD: Yeah. Mike, I want to chime in here just for a second because I feel a lot of this and I'm one of those people that, um, when I was working for a company and they started talking about us coming back into the office, I started talking about my next job. Um, and I have to say that the, the primary thing for me, as far as working from home versus working in an office. Is And even when I was on the team, in fact, it was funny because the one job I was in when they started talking about us coming back, we basically paired online the whole time anyway. And so we, you know, we were, it was a mix of chit chat and talking about what we were working on and talking about work. But for me, the difference is, is that if I'm here, I get way more done because I don't have people floating by my desk going, Hey, we got a quick question or Hey, do you know how to do this thing that I could look up on the internet in two seconds? And so, you know, even when remote work was kind of a new thing, I was always pushing to get at least a couple days out of the office for that. Yeah, there is a certain level of, hey, I'm trying to figure out this thing and you know about it, or, hey, I know that you have the right kind of background to where if we sit down together, we can figure it out. That stuff does work much better in person. But you know, Dan talks about his walkabout. Well, I've had coworkers that their whole day was walkabout and it was basically them going from one person to the other person interrupting them and So I think a lot of it is just really dependent on who you're working on and what the expectations are And then I think different people thrive under different circumstances 

STEVE_EDWARDS: You know talk about the walkabout there's a cartoon that I saw years ago and I can still remember and I wish I could find it and It I know Dilbert's always had you know cartoons about stuff like this, but it shows a guy and as a developer this is something we all know, right? Where you, when you're looking at code, you sort of have to almost the way I think of it is storing your stuff in memory. You put all your code stuff in memory so you can process it, right? Just like a computer does. And so, okay, this code's doing this, this code's doing this, this code's doing this. And you see this cartoon of him getting into it and understanding the environment he's in, and then all of a sudden somebody comes in and interrupts him for some stupid question like, did you get the email I sent you? You know, and you're totally out of that. Now you got to come get back in your headspace again. So, you know, that's something it's easier to do from home. Although those of us with small kids can talk about how that gets interrupted at times. But anyway, I didn't mean to go down a whole 20 minute thing. I just thought the study was interesting in light of, you know, the whole remote versus in person work discussion that is going on.

CHARLES MAX_WOOD: Yeah, I think I think it's worth having a wider conversation about it. But yeah, it definitely interesting.

STEVE_EDWARDS: Right. And then, uh, wait a minute. No more dad jokes. Sorry. I'll make them quick. So without the rim shot, it's not the same, but I'll do my best. So two slices of bread got married. The ceremony was great. Going great. And then someone decided to toast the bride and the groom. Um, uh, question. So when butterflies are in love, do they feel humans in their stomach? Right. 

AJ_O’NEAL: It's too bad. I was muted the whole time. I was laughing 

STEVE_EDWARDS: And then uh, finally so this one might take a little explaining let me know I had to read the comments below before I understood it I heard a photographer was killed in a freak accident when a large wheel of cheddar landed on her But to be fair the people were being that were being photographed did try to warn her

AJ_O’NEAL: I don't get it. 

STEVE_EDWARDS: Cheese. You know, they're saying, 

AJ_O’NEAL: Oh, right. Oh, for the picture. Right. Right. Right. 

STEVE_EDWARDS: Yeah. Yeah. Anyway, that's it for me. 

CHARLES MAX_WOOD: All right. AJ, what are your picks? 

AJ_O’NEAL: All right. So first of all, I'm going to pick again, the Zen of Python and the go proverbs, but primarily the Zen of Python because. You know. If you don't go to church, worship at this altar, because it's a dag on good one. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules, although practicality beats purity. Rays, oops, no, that's errors should never pass silently. unless explicitly silenced, in the face of ambiguity, refuse the temptation to guess. There should be one, and preferably only one, obvious way to do it, although that way may not be obvious at first, unless you're the creator of the program. Now is better than never, although never is often better than right now. If the if the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea. Let's do more of those. And I feel like it's hard to read that and pull much positive out of our discussion about the direction that the RPCs are going to push people in terms of more nesting, more complexity, ambiguity. But Zen of Python is.

 

I it is it is my programmers Bible. Paired with the GoPro. But the two are are are kind of two sides of the same coin. They're very very similar and and one is that homage to the other when there's also there's plenty of homages to the Zen of Python. There's also Zen of Zig and a few others anyway, but yeah, yeah, I think I think that that that's something that we all will just will be happier people will just benefit so much from that, that philosophy of simplicity, explicitness, principle will be surprise. Don't, you know, yagny, like so much of that comes out of, uh, the, or is expressed by the Zenith Python. Next thing I'm going to pick. Oh, and the link I'm giving is a poster version that you can print out and hang, hang at your desk. And I also gave a, I'll link to, uh, I gave a presentation on this. I called the Zenith programming because I applied the principles more broadly because it's, they're not, they're not specific to Python. It's just, this is one of the reasons that Python traditionally was easy to learn because it had an ethos to it about focusing on the things that are important to get the work done correctly, not to get the work done in the coolest way possible. And the next thing I will pick is Olamma. So Olamma is a server Large language models. At the base level, you can run two commands. So I'm going to link to web install.dev slash Olamma. You can run, well, I guess total three commands, but, and within five minutes, this can be running. And the reason I say within five minutes is because if you, you know, have a hundred megabit connection, it'll take about four minutes to download a model. If you go with the model that's the most like chat GPT, 3.5 is Mistral. There's other models that do better or worse than chat GPT in certain metrics. There's kind of like a table saying this model is better at code, this model is better at language translation. The cool thing about this is I think this is what's going to win. I think that chat GPT is going to be proven to be unsustainable to have a general purpose model that just does everything all the time for everyone. I think that the cost structure isn't going to work out ultimately. And, and it's going to, it's going to be, uh, subject to in suckification because at some point the investors want their money back. So you can't just pay literally. It's over a hundred million dollars a day to run chat. GPT is, is what I've, what I've heard. And I, and that sounds true and that sounds, that sounds right. So the idea of breaking down and having smaller models that are more specific and more tuned to a particular thing and you you know you pick the model that's the right model. Mistral is the most general purpose model in it and it performs similarly to chat gbt in many of the different tests. But yeah anyway you can you can run this on your local computer it runs it runs awesome on Apple but it runs awesome on Apple Silicon. It's nice and snappy. And so you can just run three commands and then a couple more if you would like to actually have the web interface like ChatGBT where it tracks the sessions and stuff. I found that the models that I've tested in Olamma are more sensitive to sessions, meaning you've noticed sometimes in ChatGBT if you're talking about TV shows and you switch to talking about programming, sometimes it crosses the streams the the models that are available in a llama namely there's SQL coder llama to Mistral And then there was another general purpose one. I don't remember anyway It it crosses the streams were and there's a few models that are specifically for Python So if you're a Python coder, there's models that have been trained highly specifically on Python There's there's another one that's been trained on like 80 languages. I haven't actually tested it out. Anyway, it's It's really, really fascinating. And I have found real uses for the LLMs because the statistics, you know, a lot of times it just spits out garbage, but for really simple boilerplate tasks, it does really well. And for really simple data extraction tasks, it does really well. So you can, you can ask things like, give me this information about this document as JSON with key value pairs and stuff like that. And if you structure it well, you can do it. So, um, I think a lot is really interesting and I'm excited to see where it goes. And I'm excited to see a approach that's more specialized because I think that the generalization being you can access many models, but each model being specialized is really, really cool. And then I'm going to also pick, you know, you've heard the quote, cause this was relevant to what we were just talking about. If you want to go fast, go alone. If you want to go far, go together. I think that that kind of describes that remote work tension is when you need to work quickly on something and be efficient, silo yourself. When you need to integrate and really get the ball moving on having the pieces come together, then you need to get together. And then lastly is I'm gonna pick Webby again itself. Uh, we finally crossed the 1000 star marker. So we've gone down from being able to see every single time an individual. Stars it to now we won't know for a hundred stars at a time. And I'm super excited about this. And, uh, I was, I'm, I, I looked at the stats to see kind of what people were, were downloading the most. And it was actually kind of surprised. Canines is number one. And then Zig isn't too far behind. But. uh yeah if you haven't if you haven't if you use webby and you get value out of it and you haven't given it a star yet consider it because as soon as we get to 1.1k i break that like decimal place in the k barrier i've um i've got plans big well really i'm i'm gonna actually start making some using that or what's the there's compound there's the compound interest that once comes once you have enough of the social engagement. And 1.1, I think, is where we start to hockey stick it and really do cool stuff. 

CHARLES MAX_WOOD: All right. Dan, what are your picks? 

DAN_SHAPPIR: I'm going to keep it short, but intense. So as you guys know, there's a war going on here in Israel. I'm sure everybody's heard of it. And there are some really bad, sad news coming out. And there's some really happy news coming out, more or less at the same time. So I'll start with the sad. Uh, the sad news is you might've heard of this young woman called the Shani Loke, uh, she's, uh, she, uh, an Israeli, a young, she's 23 years old, uh, German Israeli, uh, who was visiting that Nova music festival and she was, uh, dancing there and partying and she was, uh, kidnapped by Hamas terrorists when they, um, uh, you know, raided that music festival.

They actually filmed themselves driving around Gaza with her being thrown in the back of this kind of a pickup with looking like pretty mangled, like her legs in unnatural directions. It wasn't clear if she was alive or dead and people were coming up and spitting on her and hitting her. And they actually sent that video to her family. So it was pretty...

messed up. Well, the sad news is that apparently afterwards they decapitated her and her head was found. So now we know that she's dead. And that's the really sad news. 

The happy news is that as you know, Hamas grabbed a whole bunch of hostages, one of them a young woman, a 19 year old called Ori Magibish. And the news just came out that she was rescued. So Israeli ground forces were able to rescue her and pitch battle with the people who were holding her. And she is safe and back in Israel. And hopefully the same will be true for as many of the other hostages as possible. And so that's the sad news and that's the happy news. And those are my picks today.

CHARLES MAX_WOOD: All right. Bye. Anyway.

I'm going to pick board games. 

DAN_SHAPPIR: Yeah. I'm sorry for that Chuck.I know it's kind of difficult to come up with picks after something like that. I know. 

CHARLES MAX_WOOD: I can't, I can't even fathom how people do that to other people. I guess that's the best I can put it and it still feels inadequate. So anyway, um, yeah. I mean, I'm praying for peace, but I'm praying that Yeah, that Israel is able to get as many of those people back as possible and that you all can do whatever you have to do to make sure this doesn't happen again. Anyway.

Yeah, all right. Let me get a little out of my head here for a minute. So yeah, so I'm going to pick a board game. Now I've mentioned before, I'm, you know, teaching games at this game con here in Utah. And one of the games we're teaching is called First Rat. And I'll put a link to it on the comments and stuff. But First Rat is... What it is is your rats and you're collecting items to build a rocket to the moon because, of course, the moon is made of cheese. And so... 

STEVE_EDWARDS: Green cheese, that's green cheese. 

CHARLES MAX_WOOD: I don't know if the game specifies that and it's yellow on the box, but anyway, yeah, it's still cheese, right? I played it with four people and three people and it was fun. And what you do is you basically move up the board and the rules are pretty straightforward. You're not rolling dice to move or anything like that. You legitimately choose how you're going to move your, your rats and you can get more rats. Um, you can get the ability to move your rats further. Um, you know, you get bonuses for getting to certain places on, on the, the table. Um, my one friend that I was playing it with, he's the guy that, uh, invited me to go teach at the game con. He, he likes it because you can basically Like there's, there's almost no luck involved. It's legitimately you choose how you move and then you reap the rewards of that. Um, if you land on the spot with another person's rat, then you have to give them a piece of cheese, right? But you get to pick that too, right? You, you get to choose how you move. And so you can choose not to land there and not to give them any cheese. Anyway, um, it was really fun of all of the games that we're learning, all six games, this was my favorite and it took us, I think it took us about 45 minutes or so with three people. Took us almost an hour with four people. So I think it just depends on how many people they have playing and how long people want to drag the game out. Um, board game geek rates it or has a weight of 2.27. So it's, it's pretty, uh, approachable for most people, right? It's, it's not, um, it's not the simplest game I've ever played but it's not so complicated that you're going to spend hours figuring out how to play it out of the rule book. So, um, yeah, of all the six games, this is the one that I'm, I'm liking the most. I'm going to recommend. And it's, it's awesome. So, uh, I'm going to go ahead and put a link to board game geeks so you can look it up and then also put an Amazon affiliate link in for it. Um, but yeah, uh, I'm really, really liking that. Um, I've also been reading a book, uh, lately and I'm I'm really liking it too. It's called the Business Tune Up. I still on, I think I'm still on. I was reaching for the book and I knocked something on the keyboard. It's the Ultimate Business Tune Up by Rich Allen. And it's terrific. So if you're trying to run a business, you're trying to figure out some of the things you can do to make things better, I highly, highly recommend it. It's great. And then last week, I'm just going to pick this as well. Last week, I went to a speech by Glenn Beck. 

And he was talking about the American covenant. And what's interesting, just to give a little bit of background, um, I felt pretty strongly that I needed to start another show and start talking about some of the things we can do, uh, to make sense of what's going on out there in the world and how we can live, live life in a way that empowers us to live how we believe, and I'm not going to tell you what you should believe, but I did want to get into, Hey, here's, here's how you become more aware of what's going on in your kid's school. Here's how you become. Um, more active in your local community. Here's how you pass your values onto your children. And the thing is, is that I kept pushing off what I needed to talk about. And sometime in July, I got a really strong impression that I needed to help teach people about the American covenant. And it's an idea that I'd heard floated out there before, but I, you know, when, when I get these impressions, most of the time it's me going back to God and saying, I'm not sure what you mean. And this was one of those times I actually went and I prayed, uh, just to figure it out and I got another distinct impression, um, that he was going to send some people to help me figure it out. And literally the next week, um, I got an email from the Utah Eagle Forum that they were having Tim Ballard come out to talk about this. And then, uh, within a couple of weeks, I got another notification from them that they were having Glenn Beck come out and talk about this and it really did open me up to some of these ideas. And so it's going to be a mix. It's going to be talking about some of these ideas. I'm going to be talking about, um, to some people who have a better grasp of some of the concepts around, here's how we, you know, prepare for anything that's coming, here's how we, you know, um, fight it back against governmental tyranny, all make a difference. So, um, anyway, uh, I'm going to start a new show. It's going to be called America's Destiny and, um, I'm also going to be getting into Utah politics with another show, but I don't know how many of you are going to be interested in that. It's going to be called standup Utah, but I am going to be reaching into this area and, and talking about not necessarily, you know, the fight over who's the speaker of the house and some of the timely news, but really about, Hey, how do we deal with the things that are coming our way and here, how do we live up to this promise that we have? as a nation with God. So anyway, I know that's a little bit off topic. That's why it's in the picks and I'm not pushing it at the start of the show. But I'm going to pick that. And then the last thing I'm going to pick is Tailwind and Tailwind UI. So I went and I actually paid for a license to Tailwind UI. It's both more helpful than I thought it would be and less helpful than I thought it would be. The more helpful part of it is so you effectively get um, you know, chunks of layout that you can use. And I've, I've used that pretty heavily, um, reworking a lot of this stuff in top end devs. Um, but what I wanted was like a component library I could plug in and they do have reactive view versions of some of that stuff, but it's not, it's not a hundred percent and I'm writing it in rails and I'm using stimulus JS. And so I've had to kind of fiddle with it to figure out how to do the JavaScript pieces myself with stimulus, but it's been really, really cool.

STEVE_EDWARDS: Are you familiar with Headless UI?

CHARLES MAX_WOOD:  I've heard of it.

STEVE_EDWARDS: Okay, that's Tailwind. That's Tailwind components. That's your component library. The difference between what you have, as I have a membership as well, and Headless UI is the Tailwind components is basically just layouts. Here's all different kinds of static layout components, you know, editing, e-commerce to application forms, whatever, you can just drop it in. Headless UI is your stuff like your drop downs, your, you know, your select list, your modals, all the different interactive type components that you can plug in and tweak. They're really pretty cool. And so, you know, like Tailwind is supposed to be, they give you samples, but they can be really bare bones and you can change all your classes and stuff. So you use, I use the Headless UI more so than the Tailwind UI.

CHARLES MAX_WOOD: Yeah, I'm looking at it and it looks like it has React and Vue components. 

STEVE_EDWARDS: Yep, it does. 

CHARLES MAX_WOOD: Yeah, I just want straight up HTML and then... Yeah, so I'm mostly getting what I want from the Tailwind UI, but yeah, if I were going to be writing my application using React or Vue, then I'd be pulling this in for sure. So anyway, so yeah, and I guess one more pick. And this is something that I picked up at Railsworld.

is Kamal and Kamal is a deployment strategy that uses Docker. And so effectively what you do is you you can just install it either as a Ruby Jam or there's actually just a shortcut you can copy and paste into your bash rc or zshrc or whatever file and then you can just run the Kamal commands and it'll do the thing you need to deploy but then it's just a YAML configuration. And then what you do is you go set up your servers on like DigitalOcean or Linode or Hetzner or, uh, you know, any number of the other systems out there. And it'll SSH onto the machine and install Docker, and then it'll build your Docker image, push it up to Docker hub or whatever other registry you want to use, and then it'll pull it into. Onto that machine and do a rolling restart. It does the load balancer. You can set up accessories for like Redis or PostgreSQL.

Um, and it's, it's really simple. And so, um, if you liked kind of the simplicity of a Vercell or a Heroku, then Kamal is a really, really, uh, friendly approach to doing that kind of deployment if you want to deploy to a VPS or a set of VPSs and not have to worry about the build step on the other end or anything like that. So, um, anyway, I've gone on and on and on, I'll put all those, uh, links into the comments and, uh, Yeah, those are my picks. And I think that's everything. So I'm gonna go ahead and get those links in real quick. And until next time, folks, Max out.