The Best of JavaScript and Ruby in 2023 - JSJ 575

The Best of JavaScript and Ruby in 2023 - JSJ 575

Dave Kimura


March 28, 2023

Powered by RedCircle

Show Notes

Hosts of the Ruby Rogues Podcast, Dave Kimura and Valentino Stoll join JavaScript Jabber Panel on this week's crossover episode. They talk about both of the framework's useful features and how the JavaScript framework may be applied when creating Ruby applications. Additionally, they tackle each of their advantages and disadvantages.

On YouTube




DAVE_KIMURA: Hey everybody, I'm Dave Kamira and this is another episode of Ruby Rose. Well, sort of, because today we are actually duking it out with JavaScript Jabber. So from our side, we have myself, Dave Kamira, and we also have Valentino Stoll. 
DAVE_KIMURA: And we have Steve Edwards. 
STEVE_EDWARDS: Hello. Hello. Coming from cloudy and rainy and cold Portland, Oregon. 
DAVE_KIMURA: And we have Dan Shapir.
DAN_SHAPPIR: Hey from warm and sunny Tel Aviv where the weather is great, but the politicians are terrible. 
DAVE_KIMURA: All right. And so we really don't know how this is going to go. We didn't really rehearse it or talk about it, but today it is Ruby versus JavaScript. Or maybe it's going to be Ruby with JavaScript. I don't know. We'll see how it goes. 
STEVE_EDWARDS: I prefer the latter. I don't think we need to fight it out too much, but we'll see how it goes. 
DAN_SHAPPIR: Yeah. Otherwise Chuck might have a few fewer panelists at the end of this.
Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? So if you go to 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, slash resume, we'll 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. 
DAN_SHAPPIR: I think we have an inherent advantage that if you're building for the web, you can't really get away from JavaScript. 
DAVE_KIMURA: That is true. But I guess just to bring you guys up to speed, Valentino and I can talk about what's going on with Ruby in the latest. So... We got our latest Ruby version, or the Rails version, 704. And that brought in a lot of new functionality and features. And a lot of that is also complementing the front end and what we do with our JavaScript stuff. So with the introduction of Rails 7, we're also getting Hotwire by default. And Hotwire is kind of like a umbrella for a few different libraries. We got Stimulus.js, which is a... very micro framework JavaScript front end so we can do highly interactive things on the front end. But then to complement that we also have turbo and turbo kind of gives a multiple application or a multiple page application a single page application feel. But it also does a lot more than that with broadcast. So if you update a user record on one page, it get it can broadcast it to all the other clients that are connected to that server. So it uses web sockets underneath to do that kind of broadcasting. So it's kind of like a live breathing web page. And with that, we also have TurboFrame tags, which allows us to make a server rendered call. So we'll just have, if you kind of remember back in the 90s, the iframes, it's similar to that. But it's very much different in a more modern interpretation of something like that.
DAN_SHAPPIR: That's really interesting because it kind of brings to mind a lot of the things that are currently taking place with JavaScript frameworks around trying to mix up both client side content generation and server side content generation where a client can actually, even after the page is already loaded, a client can actually issue a request to the server to get more content as effectively HTML. So it's... kind of a mixture of client side rendering and server side rendering and things happening on both sides. And it seems that in the Ruby world, you're kind of progressing towards this in the same direction. 
STEVE_EDWARDS: You have to be honest when you first said Hotwire, the first thing I thought of was the commercial for
DAN_SHAPPIR: So you mentioned the micro front-end framework. Does that mean that when you are using this infrastructure to build, let's say interactive web application and obviously you're using Ruby on the backend, the front end, do you code it in JavaScript or do you code it in Ruby and it gets kind of automatically transformed or transpiled into JavaScript. 
STEVE_EDWARDS: Well, if I remember stimulus, it's an Alpine JAS, I don't know if it's precursor or sibling. Dan, I don't know if you remember when we interviewed the guy from Alpine, it's about a year and a half ago. You're going to render it all in HTML and if you just need little sprinkles here and there of something for a select list or some page interactivity, you can just drop it in as compared to a whole framework like a viewer react. Something like that, am I correct? 
DAN_SHAPPIR: Yeah, so it can do from the very simple things like that or a copy button if you want to copy some text Or you can make it a lot more Complex using google maps and data points on the map interacting with that kind of stuff Or with video js and interacting with a video player And that kind of stuff so it it's very simple, but it can also be extended to be much more complex so one of the main selling points of modern JavaScript framework slash backends that are built on top of mostly Node.js is that you get to implement both the backend and the frontend using the same programming language. And ultimately what I'm hearing from you is that even though the front end is really simple in terms of the amount of coding that you need to do there, because most of the logic is running on the back end and we can talk about how that's starting to happen in the JavaScript world as well, but you're still in a situation where if I'm understanding correctly, you need to use effectively two programming languages if you want to implement a really interactive kind of a website or web application. Is that correct?
DAVE_KIMURA: I think that's fair to say, wouldn't you, Valentino? 
VALENTINO_STOLL: Yeah, that's pretty accurate. I mean, the more... I think the whole driver from Hotwire, from what I've seen, it's like, there's like a baseline of what's called turbo, which is like, I believe it's JavaScript, but it's written so that you don't have to write JavaScript in Rails. And that basically is like a baseline of, I just want to interactively fetch HTML from a server and swap it out with existing HTML on the page. And so those very bare minimum reactivity is all, I guess it's less reactivity, but more like interactivity concepts. Those are like kind of the baseline in the Rails ecosystem now of, okay, you don't have to write any JavaScript for that portion of it. And then as Dave was saying, kind of like... the more complex stuff, anytime you want to mix in, maybe Google Maps or something like that, then that brings in another layer on top of the Rails stack that gives you a little easier way to interact with JavaScript with your server's side components. 
DAN_SHAPPIR: So if I'm understanding correctly what you're saying is that if in the past I wanted to update content on the front end side using the runtime on the backend, it would literally require replacing the entire page. And what you're getting now is the ability to trigger updates that only update certain portions of the page and you don't have to use, like you said, iframes for it. It's just, it's smart enough to be able to make effectively like an Ajax call to the backend, but instead of getting data it's getting HTML and then swapping that HTML into the page in the appropriate parts and in that way creating the interactivity without having to reload the entire page. Is that correct? 
VALENTINO_STOLL: Yep. Yeah, exactly. And I mean, it uses WebSockets as its way to do that, to stay up to date kind of in real time, if you will. I can't really say real time, but it gives it that bi-directional aspect and kind of how that's the fundamental channel for which it does those pieces of it. 
DAN_SHAPPIR: That's really interesting because one of the big things that are currently taking place in the JavaScript world is the latest and greatest version of React, which is the de facto King of the Hill JavaScript front-end framework. They got this new capability called React server components, which effectively kind of provides similar functionality in that the that's code that runs its JavaScript code, but it runs on on the back end instead of the front end. And it generates its content, which is then transmitted over the wire to the front end and and basically just again swapped in. So in a lot of ways, it's kind of really similar to the mechanism that you're describing, even though the tech stack is really different. And I assume a lot of the implementation details are different as well. 
DAVE_KIMURA: For example, last night I was working with a charting library, and it's pulling in about 10,000 data points. And that can be pretty heavy for a browser to render when you first go to a page. And so what I wanted to do was have the page load up immediately, but then delay load that chart. So as it got the data, then it would initialize and display out the chart. And I was able to do all of that without writing any JavaScript. But then I want that chart to automatically update and insert in new data as it's received from the server or from API requests coming in. And I'm able to just write a little bit like 50 lines of JavaScript to bring in the new data and then with that new data, then have that inject into the map. So stimulus really shines when the DOM elements are already there on the page and you just want to manipulate them. But you refresh the page and the state is all on the server side. So you refresh the page, you have all the latest data, then you're bringing in the new latest data that's coming in over the web sockets and that kind of stuff. 
DAN_SHAPPIR: That's really cool. The one issue that I potentially see with this type of an approach, and it doesn't really matter whether it's implemented in Ruby or JavaScript or whatever, is that, you know, there's a joke that I make that how do you tell the difference between a modern web app and a legacy web app? that the legacy web app is one big spinner and the modern web app is lots and lots and lots of tiny small spinners. And that's kind of the thing that I'm kind of concerned about with this kind of an approach is that the fact that you're kind of bringing in a skeleton quickly, but that skeleton effectively contains very little or almost nothing. And then you bring in additional content as it becomes available or on demand. But you have like spinner placeholders until the content arrives. So you've effectively got a skeleton full of spinners and then things start to appear and replace those spinners with actual content. And then it seems like the page is loading really quickly, but in effect, it's not a super pleasant user experience from my perspective. And like I said, that's a potential problem with any implementation of this approach. So the question is...What can you do in general? I'm not even talking in a particular technology or particular programming language, but what can you do to kind of avoid this scenario, which is almost like death by a thousand cuts with all these tiny spinners? 
VALENTINO_STOLL: Well, I think the first thing is to keep SEO and accessibility in mind where when you do have all these little spinners come in, so let's say a highly reactive dashboard. I think that's like the primary use case here that we're talking about where you have 20, 30 different little panels that are bringing in their own individual data fetching from the server. And if you first load the page and if you have 30 little tiny windows, and then as it gets the data, it expands out that shift in the content layout not only hurts your SEO, but for those who are maybe a bit more sensitive to the quick flashing or the quick moving items, then that could also cause some issues there. So having default heights, so there's not as much content shift layouts and stuff happening, I think is going to be the first important thing. But one nice thing about Hotwire that we get is typically when you make a request to the server end and you're returning the HTML over the wire. Sometimes you would have situations where you are rendering out the entire response, including layouts and all that kind of stuff, even though you just need a tiny snippet of the code. So Hotwire will only render out that small snippet that's actually required. But then to your point, if the backend is having to do very heavy calculations, and it's going to take a while regardless, then we do have that kind of problem. You know, I think one solution if you are doing a charting library or something like that is you can go ahead and display out the chart, but without any data and let that data kind of flow in and animate to the data points that it's going to retrieve. But I don't know what we would do other than that. 
DAN_SHAPPIR: What about caching and CDNs? How do those kind of things fit into these this type of architecture?
DAVE_KIMURA: Normally we would cache static assets. So any user uploaded images any CSS or JavaScript pages that been generated You know that kind of stuff usually gets digest. It gets a digest hash and then stored on a CDN 
VALENTINO_STOLL: Yeah, there is even a Another aspect another layer if you will where a lot of people will have adopted like view components Which are really just like snippets of HTML that get statically analyzed on the server, and then that is cached. And then so that as it's fetched from the server can be cached as a chunk of HTML, but then as more and more pages get rendered, it'll start caching it as they get requested. So I mean, I'm curious, the whole server-side rendering portion of JavaScript seems to be falling off a cliff. And I'm curious kind of... 
DAN_SHAPPIR: If anything, there's a renaissance. Everybody's moving to the server now. 
VALENTINO_STOLL: Yeah, I mean, but what you're talking about is what, you know, how do you handle the cases where you have like empty skeletons, where you're hydrating, you know, the skeleton as it comes in? You know, that to me, I thought the solution is server-side rendering. 
DAN_SHAPPIR: Well, yeah, but...VA It kind of depends on how you do server-side rendering, because server-side rendering at the end of the day is about generating the content on the server. But that's not panacea, that's not a free lunch. I mean, it still works, that needs to happen. And like Dave said, if you're making, let's say, a lengthy database query or something like that, it could take some time to generate the data, even if the server is relatively quick. Another potential problem is that the server might be far away. And the round trip requires multiple hops. And then again, you won't get such great behavior. The thing is this. Very often, it really depends on the site. I mean, if you're creating a site that's super dynamic, like a dashboard, then you probably care less, not I won't say not at all, but you care less about the initial, let's say, startup time. You care more about how responsive the site might be once it's loaded. Also, you probably care a lot less about SEO. On the other hand, if it's a site like a shopping site, well then you need to ask yourself, do I really need to generate the main part of the content on each and every visit? Can I like, I don't know, generate much of it, like once, cache it in one way or another, and serve the parts of the HTML itself directly out of cache. It seems to make sense, but it can get kind of tricky, it seems to me, when the communication between the backend and the frontend is so dynamic. 
VALENTINO_STOLL: Yeah, and I think one important thing that we should note is that you have to be using H2 or H3 in these scenarios. 
DAN_SHAPPIR: Oh, yeah. 
VALENTINO_STOLL: And that's regardless of which back-end framework we're using or front-end framework. Because H2 and H3, for those who don't know, is going to specifically introduce an HTTP2 that you can use one connection to request multiple assets. So you don't have to do several SSL handshakes to request several different images from the same server. So that's going to be a must if you are doing a lot of these little tiny loads. 
DAN_SHAPPIR: It does something known as multiplexing. It basically enables multiple HTTP downloads over a single connection, rather than requiring multiple connections and only allowing one download per connection at a time. But I think this is more or less almost a given these days. I'm hard to...
VALENTINO_STOLL: No, it's not. No, I've still come across sites that are serving HTTP 1.1 and they're downloading like 50 different things on that page. You can only download six at a time, I think. Is that correct with HTTP 1.1? 
DAN_SHAPPIR: The funny thing is the reason that it can download six is that when the connection to the server is HTTP 1.1, the browser will actually open six TCP sockets to the backend so that it can do six HTTP downloads in parallel, one over each socket. So that's the reason you see the six download limit. With HTTP2, it actually opens only one TCP socket, but like I said, it can actually do multiplexing on top of that socket, so it can actually download multiple resources over that single TCP connection. And HTTP3 actually replaces TCP with a different underlying protocol, which is actually implemented on top of UDP, and is more, let's say, modern web friendly, because you know all these other protocols, TCP is a protocol that's like what, 50, 60 years old? I mean the internet today is a different place. So yeah, things have changed. I'm kind of surprised. I mean, if you're using modern infrastructure, modern hosting or modern infrastructure, then you should be getting HTTP 2 or 3 out of the box. 
VALENTINO_STOLL: Yeah, I think it's just how some websites have it configured. I know if you throw Cloudflare in front of there and enable the proxy, then you get H2 by default. 
DAN_SHAPPIR: Yeah, that's pretty standard for any CDN provider these days. So if I may ask, you know, coming from the world where everything is JavaScript, because, you know, like you can't get away with it from JavaScript on the front end, so it's like, you know, if I might as well also use it on the back end, and especially use effectively the same templating mechanisms on both the front end and the back end the big advantage or the main advantages of using Ruby instead of JavaScript on the backend? 
VALENTINO_STOLL: It's pretty self-explanatory to me. 
DAN_SHAPPIR: For sure, go for it. 
VALENTINO_STOLL: The biggest thing I see is just ease of readability. There's a lot less characters you have to read through. Even in TypeScript, there's still a lot of like visual lifting you have to do to read through how maybe something works. It's something you get used to over time, but it's not as easy to switch between languages. So as an example, I'm a Rubyist. I probably do more JavaScript than Ruby at this point. Unless JavaScript, but frameworks of JavaScript, right? And it's very easy to transition between languages because Ruby is kind of like the baseline. It's like no frills. There's no very little syntax in the way of, oh, mostly words. And from there, you know, going from something with more syntax is kind of easier because it's like, well, you know, I had the words, but now there's just like the little extra stuff in there. And so it's like kind of it's. For me, it's easier to transition between many in that way. But I prefer Ruby specifically for the absence of syntax. 
DAN_SHAPPIR: Oh, I understand that it's a object-oriented programming language with a functional bend. Would that be a good general description of it? 
VALENTINO_STOLL: It's getting better. It is definitely object-oriented first, but people like to, as you say, bend it to be functional in many ways. 
DAN_SHAPPIR: I know that it has lambdas and stuff like that. In fact, it makes a lot of use of those sort of things, doesn't it?
VALENTINO_STOLL: Yeah, exactly. And I mean, that's that that's kind of the way that it is functional in a way in that it makes heavy use of passing, you know, blocks of code around. But I would say it's less of an asynchronous-capable language than JavaScript maybe is. JavaScript is kind of functional by default. 
DAN_SHAPPIR: Well, it wants to be. In a way. It isn't exactly. 
VALENTINO_STOLL: It wants to be. 
DAN_SHAPPIR: Question, though. So you said that it's less asynchronous. Is it a multithreader? And I apologize that I'm asking questions on a Ruby podcast that all the Ruby listeners probably all know the answers to. But is it a multi-threaded programming language or a single-threaded programming language? 
DAVE_KIMURA: I'd say it's single-threaded, but it can sort of do multi-threading. So you can thread together multiple things together, have them run asynchronously. And if we're talking about just Ruby on Rails and web designs, we just kind of scale by adding in more workers. So if you have a large machine, you just scale up more services to handle more requests. And then you can horizontally scale and add more servers beyond that. 
DAN_SHAPPIR: Understood. 
VALENTINO_STOLL: And there are versions of Ruby that are multi-threaded. So if you want that capability, you can use it using a certain runtime of Ruby. 
STEVE_EDWARDS: So getting down to the basics, I mean, for me, Ruby has always either been a gem or a title of a song by Kenny Rogers. But what is there's Ruby and there's Ruby on rails. So what is, is rails built on top of Ruby? What it is, what's the difference or how do they work together? Let's put it that way. 
VALENTINO_STOLL: Rails is to react as JavaScript is to Ruby.
STEVE_EDWARDS: So it's the front end tool for... Yeah, 
VALENTINO_STOLL: Rails is the framework. Yeah. 
DAN_SHAPPIR: Yeah, but it's a framework that's mostly about data access, isn't it? Less about UI construction or am I getting it wrong? 
VALENTINO_STOLL: I mean, so does Rails do the actual HTML rendering? 
VALENTINO_STOLL: Okay. It's a full stack. So it takes, it tries, you know, originally it was, you know, the blog engine, right? You know, you watched the creator DHH create a blog in 10 minutes was like his original pitch that made, you know, made it so popular originally. And, you know, from the back end, making that modeling the database all the way to the front end, you know, making a crud, you know, create a blog post, enter a title and save it to the database and then be able to view a blog. Right. Like that whole stack from the back end to the front end was all reels. And it's encapsulated that idea of, okay, if you need to build something on the web, you can use Rails as a framework to do that. 
STEVE_EDWARDS: So it's sort of like the whole, what's the term, Dan, where you use the same language? Isomorphic? 
DAN_SHAPPIR: Well, no, because it's not running Ruby or Rails on the front end. Isomorphic code, which is a term that's hardly used anymore, by the way is about running the exact same code on the front end and the back end, which is kind of the way that React works. But in the case of Ruby on Rails, it's kind of by definition not the case since you can't be running Ruby on the front end unless you transpile it into JavaScript, which is- 
DAVE_KIMURA: Or WebAssembly. 
DAN_SHAPPIR: Or WebAssembly, which is what most people don't do. 
VALENTINO_STOLL: But- There are people that do that. 
DAVE_KIMURA: Yeah, you know, brave souls. But one more thing if I recall about Ruby and maybe again, maybe my knowledge is either updated or my recollection is incorrect, is that it uses a lot of conventions to speed up development about how it kind of maps items or data in the database into objects and in memory or stuff like that. Is that correct? 
DAVE_KIMURA: Yeah, so we do have an ORM object relational mapper called ActiveRecord. And it makes it very easy to interact with the database. So if we have a table on the database called users, and that has several columns, first name, last name, email, then we can pull up that user with like a user.first. And then with that object, we can then call user.firstname, user.lastname, and that's immediately pulled from the database. So it's putting it into the server memory while we have that object initialized. And once the request is done, it often should release it from memory. 
DAN_SHAPPIR: And that's something that's kind of wholly missing from the JavaScript world. I mean, I'm sure somebody did it because somebody does everything. You know, everything, what's the saying? Everything that can be done in JavaScript eventually will be done in JavaScript. So I'm sure somebody did it. But most people don't. I use ORMs directly from JavaScript. Rather the JavaScript does some sort of a fetch or RESTful API or GraphQL request to some other backend service that provides the data. That's what I most commonly see. For example, where I work, which is a company called Next Insurance, nothing to do with Next.js, it just happens to be the name. Our front end is obviously implemented in JavaScript, part of it in React, part of it in Angular. We use node servers as the backend to those front ends, so they communicate with node server backends. But those node server backends actually get data from microservices that it's those microservices that actually interact directly with the database. So the node itself doesn't interact directly with the database. It always just makes API calls to microservices that are also running on the back end. And those microservices are actually implemented in our case in Kotlin, which is a programming language that compiles to and runs on the JVM, kind of like Java. It's kind of like a nicer version of Java.
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 that 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. Really looking forward to diving into it. That's February and March, April and May, we're gonna be doing the Pragmatic Programmer. And we're gonna be talking about all of the kinds of things 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 gonna 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 gonna get you ahead in your career then definitely come join the book club. You can sign up at top end slash book club. 
VALENTINO_STOLL: Yeah. It's just amazing what you can do with Ruby. Like, uh, last night or two nights. So I created this monstrosity in Ruby. That's a lot of fun. So I created an active record, um, wrapper for Redis. And so I needed to store a bunch of data only temporarily for however long that Redis server is going to have it. So it works just like it would, you would expect any other active record object and Rails to work. And it'll just bring in a bunch of data stored in memory on Redis. And then I can just pull it down and interact with it, just like I would any other active record object. So it made my development. Actually creating that wrapper was a pain. I had to get down to the lower level Redis functions to set and get the data. But then once I did that, actually consuming that made it so easy. And I actually made it reusable so I can use it for other things as well. So just the power of flexibility. And this is, this can be said about any language really. But with the Ruby on Rails framework specifically, just having a lot of this built for us already makes it so much nicer and easier and faster to develop and work in. 
DAN_SHAPPIR: By the way, Steve, how do you do data access in your projects? 
STEVE_EDWARDS: Funny you just asked me that. I was just about to ask a couple of questions about that. So most of my work, at least for my day job, is a combination of you and Laravel, if you're familiar with Laravel, which is a PHP framework. And so there are a couple of ways to interact between front and the backend. If I'm doing a front end, like a small project, sometimes I'll use a headless CMS, like a Prismic. There's Contentful, there's Sanity, there's all kinds of them out there. And they will have either REST or GraphQL APIs that you can call from your front end or your backend, depending on what framework you're using. With Laravel there's actually a couple of different ways. The way in our large app, it's been around for a long time, is Laravel will create REST API endpoints with your posts you put, you get your patch, that kind of stuff. And so from your front end, whether it's in a state management, such as Vuex, I'm primarily Vue is what I work in, you'll make your REST API calls, using a library like Axios, which returns a promise, and then you get your data and do what you need to do with it. So first question is that if I if I was to use view with react for instance, is that the same approach you'd use in terms of just generating standard rest API endpoints from root from Ruby? Or is there another way that you would pass data back and forth between the front and the back? 
VALENTINO_STOLL: We really don't worry about state or that kind of stuff on the front end, especially if we're doing Ruby, because it's all server rendered. 
STEVE_EDWARDS: Yeah, it takes data out of the picture. That's just one way. But just how would you how would you pass the data back or could you use. Would you use like a viewer react or Svelter and Angular with Ruby on the back end and if so how would you connect the two. 
VALENTINO_STOLL: You can do that. I'm a big. I'm on the opposition side that you don't need react view angular or any of the big JavaScript front end frameworks to make a good Ruby on Rails application. That wasn't the case five years ago, where we just didn't have all these front end components built for us with Hotwire, Turbo, and just the broadcast between the two. But I just, I don't see that being the case anymore. 
STEVE_EDWARDS: So Ruby tends, sounds like it tends to be pretty insulated then you built everything you need within the Ruby Rails community and then use those tools as compared to maybe integrating uh you know a javascript framework with with a sole ruby backend
DAVE_KIMURA: Yeah, it's kind of where I think as Rails developers and Ruby people in general, uh, it's kind of in the, at a divide right now where there are people where they believe, okay, the front end should be completely separate from the backend. They like the very, you know, single page application, uh, you know, have your front end code do the front end stuff. The backend code can still handle the backend code. And when there's some blend, we can take advantage of features that you know, are offered in the framework for Rails in this case. And then there's a whole other group that believes like Dave, you know, server side are like these, you know, do everything in the server and just, you know, have the page dynamically update based on the HTML that we get from the server. Um, and forget about all of the front ends because they're not needed. Right. 
STEVE_EDWARDS: Um, yeah. So it's in the JavaScript world. Basically, well, I guess in the web development world, it's really been interesting to see the whole pendulum swing back and forth. And so, you know, when I first started dealing with websites late nineties, early 2000, you know, it was LAMP stack, right, PHP, and it rendered HTML, get into Drupal where you're using PHP template as a templating language, but it's still all server, you know, everything's server rendered. Every interaction with your page requires a server request and to return updated data. Then you start getting jQuery. So you can drop jQuery in here front end. You still have to wait for all of these server-regulated content to be completed before jQuery can attach to the DOM nodes. And then you can do your interactivity and stuff like that. But you're still running full post request to your back end. Then you start getting calls for decoupled back ends, where you can have a Drupal or WordPress, maybe your Rails, that's solely your back end. And you're passing data to a whole JavaScript front end. Well, then you got Node.js comes out around 2013. You start seeing JavaScript on the back end. Then you've got Angular, which came out of, it was taken over by Google. It didn't come out of Google. It was taken over by Google. And there's your first JavaScript, full JavaScript framework. Then you get React. Then you get Vue. Ebon, you came out of the Angular team and created Vue.js. And there's other ones, there's Ember. Pretty soon you're exploding with JavaScript frameworks. Everything's in SPA. You gotta load everything in JavaScript. Well, then people start seeing the performance issues and the SEO issues because the bots don't really wanna wait around for the page to get hydrated with all your data. So your data, your SEO is horrible if you're using, you know. 
DAN_SHAPPIR: Not just the bots, users don't like it either so much. 
STEVE_EDWARDS: Yeah, yeah, because they're waiting. So then you start to see the pendulum as we backwards to server rendered. You see next, you see next, right? The JavaScript frameworks with their own what were called meta framework. And then now you're starting to see stuff like Astro, which is something I'm a fan of where it's It's interesting you. It's all server rendered stuff, and but then you can integrate. Well before that even started seeing stimulus or Alpine JS or stuff like where you can drop the install server rendered and then you drop them little sprinkles here and there. Then you see Astro and stuff like Astro where everything comes from the server and you can actually query your query my APIs. I've done one like this with Prismic where you're querying in node. or in JavaScript you write your API calls to your back end, but it's all server rendered. But then you can plug in framework components. You can plug in a React component, and a Vue component, and an Angular component, but just where you need it. There's pros and cons to this approach, and purists don't necessarily like that. Everything's coming back to server rendered and just drop in the JavaScript where you need it. Now, another tool that I'm a big fan of, and I've talked about it, and I've talked to the JavaScript Jagabird Dabber, I've introduced the creator, Jonathan Reinick, a couple of times. It's called the Nurture.js. And I bring it up here because it has a Ruby plugin. And so what that does is sort of a glue between front ends and back ends. So I can use Laravel with Vue. You could use Ruby with Svelte. You could use Ruby with React. You could use Ruby with Vue or Laravel with React. It's basically just a library that connects the front and the back end. You have adapters for the front and the back end. Basically, what it does is, my description is to hijack the post request and you're not sending, it just sends the data and then the data from the back end gets piped through this library and passed as prompts, in React and Vue, called props. I'm not sure how you do it in Sevelt. But you're not getting the full browser reload and page request, so it's super quick. And it's a lot of fun and it's great. So if you know Ruby, you can use that solely for your backend. And then if you want to use it, a framework, you know, for your front end, this wouldn't be good for like a standard, like a brochure webpage or some sort of informational thing, I see it as more as a use for something highly interactive, some sort of dashboard, you know, I'm using it to create a sort of a credit app for an organization that I belong to. But all that to say there's there are ways to sort of plug and play Ruby with other things if you want to, you know, if you want to break out of the whole Rails ecosystem, whether it's for familiarity, can be any number of reasons. But that was where I was going with the whole question about how you plug and play and some of the options that exist, if that's something you want to do. 
DAN_SHAPPIR: But if I can go back to something you said at the beginning, you gave a great description about how and it's really interesting because I've obviously, I think all of us have been long enough in the game to have seen this happen multiple times. And even though it does seem that the Ruby community or Ruby approach is more stable than the JavaScript one. I think a couple of things coming to play here, you know, as what people develop kind of changes, you know, people started developing more sophisticated stuff on the web people were starting to run into the limitations of existing technologies. And so they came up with different new and different approaches like SPAs instead of MPAs, single page applications instead of multi-page applications. And which brought in another aspect which Steve and I have discussed in the past in which ideally people should be using the best tool for the job, but practically people often use the same tool or try to use the same tool for everything. So new technology is kind of because, you know, it's just easier for people not to have to learn new things. And also in organizations, it's always kind of easier to standardize on stuff. So that kind of causes people to overcommit to certain approaches. So, you know, I'm seeing the limitations of MPAs. I'll bring in the SPAs for the use cases that really need it but then I'll start just doing everything that way and all of a sudden the pendulum is swung too far and now everything is an SBA and we're running into problems with that approach. So then the pendulum starts swinging, you know, back again. And it seems to me that based on the way that you're describing things and I must, might be misunderstanding, but that the Ruby community in general, and especially Ruby on Rails, seems to have been much more stable in their approach where JavaScript has kind of been all over the place and, you know, trying a whole lot of things. You know, there was a term JavaScript fatigue a few years ago, then everybody kind of standardized on React for a while, and now we're getting, and now everything is up in the air all over again, and there are like multiple frameworks coming out, literally out of the woodwork, and nobody's really sure what we'll be using in two years from now. So. Yeah. It's interesting to make this kind of contradiction. 
DAVE_KIMURA: Well, I mean, to be fair, Ruby or, you know, specifically Ruby on Rails had its growing pains as well. You know, back, um, geez, I think it's been like six years or eight years. We really didn't have a good solution for the front end. So we brought in, uh, coffee script and we use CoffeeScript very heavily, but we still didn't have any good way of managing what version of what JavaScript library we're using and that kind of stuff. And ultimately we got Webpacker, which was a rubious approach to Webpack. And that really changed on how we were introducing JavaScript into our applications. You know, like you said before, something you just said about, you know, everything becoming a single page application. I think that's true and that's one reason why I love the direction that Rails has gone because yeah, we could use Ruby for everything, the front end, the back end, just everything, or we could pick the best tools for the job. You know, I don't think React is the best tool for the job in a Rails application, but for a while it was a sensible choice to sprinkle it in where needed because we still didn't have the answer for highly interactive client side experiences. And I just don't think that's the case anymore in a rail seven application. 
DAN_SHAPPIR: React had two main things going forward from my perspective. One is the fact that both of them stem from the fact that from one point, which is that it had a really lively ecosystem because it was the de facto leader in front end development and the outcome of that was that you could find people, you could recruit people who are knowledgeable in React relatively easy or easier than other technologies and you also had a lot of components and reusable code that you could be using because everybody was creating their components for React. So those were the main advantages there. By the way, if I want to use a particular component, say you need some sort of a fancy date picker or a combo or whatever in your Ruby on Rails implementation, what would you use these days? 
DAVE_KIMURA: I would probably try to find a vanilla.js library, so like select two I think or something like that and just bring it in and wrap it around a stimulus controller and then use it so it's contained and easy to maintain. 
VALENTINO_STOLL: Yeah, I mean, this brings up a good point of like, where your end user is, right? And I think that's kind of why this pendulum keeps swinging is, you know, there's been a huge shift towards people on their phones, right? And, you know, we saw such a big change in all ecosystems when everybody had a phone all of a sudden, and, you know, we needed to make the browser better for those cases, right? And there was a long time where, oh, well, does it work on like 80 different devices using all different kinds of implementations of the browser's APIs? You know, JavaScript was not very strong choice because it could work completely different depending on what device you had. And Flash was a nightmare. 
DAN_SHAPPIR: Wow, you're going way back. I think the more- 
VALENTINO_STOLL: Well, I mean- Let's evolve even to like more recent, uh, you know, evolutions of JavaScript, right? Where, uh, you know, the browser APIs are very nice. Uh, you know, it's making JavaScript a stronger choice for a lot of people because you can do a lot of the same stuff for whatever clients that you want. Uh, but it's still at the same time, um, you know, devices are continuously changing and evolving. And I think what we're seeing now is, all right, people are, you know, where is your end user, right? Like, are most people at their desktop? Are they at their phone? Does it matter? You know, and but what are their capabilities, right? Like on your phone, it's still kind of hard to like upload an attachment cross platform using anything, APIs, you know. 
DAN_SHAPPIR: So to be fair, browsers in terms of APIs have come a long way. The days of incompatible APIs between browsers are mostly behind us. There are still issues with Safari mostly these days, especially given the fact that on iOS, you've kind of locked into Safari and Safari is a bit of a laggard in certain scenarios. So it's not that it's implementing different APIs, it's implementing the exact same APIs. It's just that it's missing some APIs that you would like it to have. But the bigger issue is one that actually, we had Alex Russell, formerly of Google, now at Microsoft. He's really big in the web standards, you know, W3C and the ECMA group, which is the one working on JavaScript itself. And the point that he brings up is mostly about the digital divide, the growing digital divide between the haves. I wouldn't say have-nots, but I would say have-less. The fact that, like you said, we are all on mobile these days. You know, obviously a lot of people still use desktops, but most of the web is mobile web. Like, I don't know, sometimes like 70% of all web sessions are from mobile devices, if not more. Some parts of the world, it's closer to 100%. And there's apparently a huge difference between the top end devices and the lower end devices. You know, we as people who are working in tech and living in first world countries have the benefit of, let's say, using the latest and greatest iPhone, whereas a lot of users are actually on mid-range Android devices, and the disparity between the capabilities of these two is only growing. It's like the iPhones are like 10 to 20 times faster than the mid-range Android devices. So think about whatever your experience is on your mobile device with whatever web application or website you're developing, then think about it as being 10 or 20 times slower. And that's the experience that some of your users are potentially having, simply because they're using a device that they bought at Target for $200. So that's a big issue these days. And that's part of the reason that's driving a lot of people back to the server side. Because we just can't keep on pushing more and more code and execution to the client. If everybody was on an iPhone and the latest iPhone and a 5G network, then maybe we could. But that's not the reality for a lot of users. 
VALENTINO_STOLL: Yeah, it's kind of funny. I throttle my browser to 3G just anytime I'm testing something for that very reason, because it is a huge issue. Even just think about yourself with a brand new iPhone, if you go down the street and you hit a spot that isn't covered in a wonderful network, you're stuck just like somebody who has one of these knockoff Android phones, right? with a very similar experience. 
DAN_SHAPPIR: Or if you're traveling overseas and you're on some, you know, data plan and really limited connectivity and whatnot for sure. Yeah. And in that regard, the approach that you're describing with Ruby on Rails of, you know, using minimalist JavaScript, sending in HTML sections as needed is a really good approach, it seems. I haven't tested the performance of those. It'll be interesting to do so. But it sounds like a really good approach. 
DAVE_KIMURA: Well, back in 2014, we got the iPhone 6. And that was an amazing phone. It was a flagship phone at the time. But its speedometer 2.0 score was around 24. Fast forward a few more years, the Apple iPhone X has a speedometer to point a score of almost one hundred and the iPhone twelve pro another flagship phone has a score over two hundred. So we are getting like exponentially faster on our mobile devices where back in twenty fourteen and earlier I mean as you are saying it was just a horrible experience. No you didn't have for the LTE network and everything was slower.
DAN_SHAPPIR: Yeah, but take into account that the new Galaxy A23, in terms of its multi-core bench score, is equivalent to an iPhone 7. So that's a new phone that came out in 2022, and in terms of iPhone. And so this gap is increasing. That's what I'm saying. iPhones have been getting progressively faster. The mid-range Android devices have been getting a bit cheaper, but having the exact same performance profile, or more or less, over the past five years. And that's what I'm saying, that the performance gap is kind of growing. And that's one of the reasons that driving JavaScript towards a similar approach to what you're describing in Ruby of shift, of trying to shift back computation from the front end back to the back end. And, and kind of goes to what Steve described before about how the pendulum kind of swings back and, and, and, you know, let's, let's see how we can download less JavaScript. Let's see how we can do computation on the server side. It's interesting. What goes around comes around, or, you know.
VALENTINO_STOLL: Yeah, you know, and I bring all of this up because I'm curious. I'm not sold that it's going to go one way or the other still, right? I feel like this pendulum is still swinging and I feel like, you know, while there is this huge gap, people are going to continue to develop more client heavy applications. At the same time, they're also going to continue developing higher, you know, more server backend stuff. And because of these disparities, depending on your use case, right? Like one is going to be more favorable than the other and there's going to be a middle ground either way. And I'm, there still isn't really a winner, right? Because there are so many different, you know, edge cases. 
DAN_SHAPPIR: I don't think that I'm not even sure what the concept of a winner even means. Really, I mean, you know, all of us, the four of us are used, well, you two seem to be using the same technology, but Steve and I even though we're both JavaScript quote unquote people, we're using really different stacks and all of us are making a living, pretty good one I assume. So it just goes to show that all of us are winning using really different stacks. 
STEVE_EDWARDS: So to your point, Valentino, you were talking about the different tools and how things keep changing. I mean, one of the nice things that I see about the open source software community is that there's always innovation going on. Someone's figuring out something new. You know, the one of the ones that comes to mind that seems to be getting a lot of traction is a guy that we had the opportunity to interview twice on job search, ever was Mischko Hevery. And so as an example, he's building a whole new framework called quick. Um, obviously I think the, the name is a play on what it's trying to do. And my head still spins trying to understand all the, how he's storing data to make resuming an app very quick. And so you're not having to reload from the server and so on. We talked to him for probably what, three hours total about Quik and what it does and why he's building it and stuff. And that's not to focus on Quik itself. My point is simply there's always going to be innovation. There's always people trying to do something new, something better. There's a classic XKCD cartoon about there's already 14 different frameworks. Oh, but I think I can fix this one. Oh, look, now there's 15 different frameworks. And the term JavaScript fatigue is...It seemed to slow down for a while, but now it seems to have picked up again. I mean, it's just because there's always some new tools, some new framework, you know, bunjs is another one that comes to mind. You know, that's supposed to help speed. Everything's about speed, speed, right? And so I don't know, you know, I don't think there will ever be a consensus on what is the best, what is winning, you know, what is the right way to do things. People are gonna have different use cases for different frameworks. And I personally don't see an end. 
DAN_SHAPPIR: If there's anything that's going to end JavaScript fatigue is the fact that all the JavaScript developers are moving off of JavaScript and into TypeScript. So instead of JavaScript fatigue, we'll have TypeScript fatigue.
STEVE_EDWARDS: Yeah, but you don't hear about TypeScript frameworks. You hear about JavaScript. TypeScript is basically just a superset that, you know, 
DAN_SHAPPIR: Or the way that AJ likes to call it, it's a superset of a subset, which makes it a totally different thing.
VALENTINO_STOLL: Yeah, you know, I will say, I think one thing that Reels has had going for it, you know, from the get-go is kind of its business focus, right? Like, You can build your MVP really quickly and get it out to most people. And I think that's kind of what's helped Ruby in that Rails has been very much a framework for business people. And Ruby has kind of gotten the popularity of, oh, well, if I want to start my own business, I can use Rails and subsequently Ruby to make money, right, and hire people. And I think that's what's gained a lot of popularity and made things not change too much because it's very business focused. And I think from my view of JavaScript, I'm a JavaScript developer, but it's kind of just like, you know, it helps. And it's less of this is what I can use to build my business. And that is changing. And that part of the pendulum is well, it can help me build my business. But I think that's one part of maybe these framework wars, is nobody has come out and said, OK, you can build your business with React. It's more of, oh, businesses are using React, and there's developers in React. And so I'm curious to see how that evolves, and to see maybe because there are so many things you can do with just Node. Right? from the server side and people are using it as both. So I'm curious to see maybe how it evolves in that way where people are making more framework-y things from a how do we make money and keep people hired kind of. 
DAN_SHAPPIR: So it's an interesting point that you bring up and maybe we can start summarizing with that is that React in particular was originally not even positioned as a framework. It was positioned as a library for generating the front end or the viewport. So it wasn't really a full stack solution for your business. It was intended for a very particular aspect or part of the solution that you might be building. It's really interesting because these days it's actually undergoing a sort of a metamorphosis kind of becoming a full stack. There's something called React Server Components. It's kind of being subsuming or being subsumed by Next.js. And in that sense, I'm thinking that a future version of Next.js with React, with a future version of React, might actually be positioned as an alternative to Ruby on Rails in this regard. 
VALENTINO_STOLL: Yeah, that'd be interesting to see how well that plays out, you know? 
DAN_SHAPPIR: Yeah, aren't we all? We're actually going to have Dan Abramov, who's this really big name in the React community, works at Meta, so he's going to be a guest on JavaScript Jabber in about a few weeks to talk about the future directions of React. So this is definitely gonna be interesting. 
VALENTINO_STOLL: Well, do we have any final takeaways other than just use Ruby? 
DAN_SHAPPIR: All I can say is that I remember it was a few years back, I was at this largest meetup and a lot of representatives from different companies and I was the kind of schmoozing and I was asking different people which technologies they were using, you know, in their stack. And everybody was using something different on the backend. You know, some were using Ruby, some were using Java, some were using PHP, some were using other things, but everybody was using React on the front end. So, you know, time will tell what happens. We will see. 
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 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 going to actually brainstorm together. You and whoever else is there and I, all of us are going to brainstorm on how you can get ahead. Um, the next week on the 14th, we're going to 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 going to do a Visual Studio, uh, VS code Tips and tricks. On the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally, on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have along with the book club. And I hope to see you there. That's going to be at slash sign up. 
DAVE_KIMURA: All right. Well, I'm going to push this over into. What are we currently working on or has our piqued our interest? So I'll go first. I've been diving into Python lately. I've been doing a lot of machine learning learning and it's been quite the road. And I must say I much prefer Ruby over Python because I really hate my language dictating my white spaces. It's so annoying. But Python is like the de facto language for machine learning. And I figured that would just add another tool into my tool belt. So I've been diving into that lately. I initially tried on AMD cards, but found that they were finicky at best. So I did pick up a 4080 Founders Edition for playing with and for machine learning. And I love it. It's so nice. So.That's what I've been doing lately. 
VALENTINO_STOLL: The Founders Edition, what is that? 
DAVE_KIMURA: Nvidia RTX 4080 graphics card. Oh, card. OK. And Valentino, what's got your interest lately?
VALENTINO_STOLL: In a similar light, I'm heavy into machine learning at the moment, mostly around embeddings and generating vectors and storing them and performing analysis on it like that. It's kind of exciting. We use Neo4j, which is a graph database. So I'm learning how to store vectors in that and being able to query on them and run the calculations in Neo4j, which is interesting. But it works well because it's a graph database and that's kind of what it does. So we'll see, time will tell, but I'm kind of enjoying how easy it is to play with all this stuff. I have very little machine learning experience, so I'm able to get started really quickly, which is kind of incredible. So I'm excited to see what else I could do with it.
STEVE_EDWARDS: You know, it's interesting you're talking about machine learning because as of today, I have to do the same thing only because we are hiring at my place of work. And I'm sort of in charge of doing the hiring. And one of the things we're looking to hire as a data scientist and considering I know absolutely nothing about any of that, I'm having you dive in so that I don't sound like a complete moron when I'm trying to interview people for a data scientist. So I've been looking at TensorFlow or Python and just trying to figure out how the heck all of this works. It's an interesting note. I have a friend, an old friend from college who is very big into machine learning in the biosciences field in genetics. And so she uses a language called R, just the letter R, which is, as I understand it, very big in the scientific community in terms of processing. 
DAN_SHAPPIR: It's a good language for doing all sorts of computations and statistics as I recall. 
STEVE_EDWARDS: Right, yeah, that's my understanding of it too. So yes, I am not by choice, but by force, I'm having to delve into machine learning and just trying to get my head about data models and processing and how all that works. 
VALENTINO_STOLL: I've heard from somebody at OpenAI talk about kind of hiring and getting teams to work with their APIs and They've seen a huge internal struggle with their data teams in that their models work so well that it kind of obviates the need for any other traditional maybe re-workings or traditional thinking in machine learning that is typical. So what they've seen is a very hard adoption of people that are already currently in that machine learning world adopting kind of the new large language model thinking. And I thought that was a kind of an interesting take. 
DAN_SHAPPIR: I will say though that Steve, there are, you know, APIs, pretty good ones even for TensorFlow, for example, from JavaScript these days. So you don't have to use Python if you don't, you know, if you prefer to use JavaScript instead. 
STEVE_EDWARDS: No, that's, I mean. We have a whole backend crew that deals with all the server side stuff that isn't JavaScript knowledgeable. So having to use JavaScript isn't a requirement for this. 
DAN_SHAPPIR: I understand. I'm just saying that for you, if you want to play with these APIs. 
DAVE_KIMURA: You know, the problem with that, I found because there's Ruby wrappers around PyTorch and that kind of stuff as well. But I found that as soon as you need something and you have deviated from the community standard way of doing it then any kind of documents or references can be a hit or miss, whether or not it'll apply in your application. So you might be banging your head against the wall a lot more than you would have to if you had just gone the community standard route. 
DAN_SHAPPIR: So you're saying Python is essentially the mainstream. And when you deviate from that, you're running a risk. 
DAVE_KIMURA: Yeah. I think that's very fair to say. 
DAN_SHAPPIR: Sounds right.
DAVE_KIMURA: So, Dan, do you have anything that's piquing your interest? 
DAN_SHAPPIR: Yeah, so I've not been doing a lot of open source for various reasons in the past few years. Mostly I've just been too busy. But recently I found myself kind of engaged in an open source project. I'm really heavily, my day job is mostly about web performance and that means collecting a lot of data and graphing a lot of data and one tool that I've been using for that is something called Prometheus, coupled with Grafana. So it's like this kind of like a database that you can throw data into it. And then you can really easily create all sorts of graphs over this data. And we ran, we are still running into all sorts of performance issues. So the Prometheus client for JavaScript for Node.js is obviously an open source project. It's actually even an unofficial client. It's a pretty popular open source project, but it's not an official part of the Prometheus package. It's like some labor of love by a member of the community. So I started optimizing the code and contributing my optimizations back into this project. So it's kind of a fun to be doing open source stuff after such a long period of time. 
DAVE_KIMURA: Cool. Steve, do you have anything that you're working on or are peaking your interest? 
STEVE_EDWARDS: Well, like I said, there's the Mesh Machine Learning. Then what I had talked about earlier is I'm really getting in playing with Inertia.js because for me, it was a tool that allowed me to plug and play what I knew best in terms of backend to frontend and mix them together in a way that's really quite performant. Usually if I wanted to do some front-end project that used a CMS, I was using a headless CMS, but I don't like those because sometimes I really want fine-grain control over my data storage and how it's modeled and accessed and all kinds of little tweaks. So using Laravel with my SQL database really gives me the control that I'm familiar with and I like. So it allows me to control everything, start to finish, in a way that makes it easy for me for my particular application.
STEVE_EDWARDS: And then, hey, before we leave, one thing I wanted to bring to the podcast is the dad jokes of the day. Something I do on JavaScript Jabber and views on view. And sometimes I can get Dan to laugh. A lot of times he just rolls his eyes, but I know that I get love from other places too. So I'll throw a couple out there for you if that's okay. One of my favorite genres of dad jokes is cow jokes.You know, so for instance, we all know, or we should know, I would think that you call a cow with no legs ground beef. Right. And so the opposite of that obviously is high stakes. Right. And then the other day I went to, I went to the plagiarism store and I tried to pay cash, but they would only take credit.
DAN_SHAPPIR: Okay, took me a second to get it. 
STEVE_EDWARDS: And then finally, whatever nationality you are while you're doing the potty dance, what nationality are you when you're done? Finish.
VALENTINO_STOLL: I got one more for you. 
STEVE_EDWARDS: Go for it. What do you call a cow that's just had a baby? 
STEVE_EDWARDS: Decaffeinated Yes You know, the cow with two legs is lean beef or Eileen and yeah, there's all kinds of great ones Here's what do you call Valentino? What do you call a cow that doesn't feel pain? Just a C right no ow
VALENTINO_STOLL: Knock-knock. That's a good one. 
STEVE_EDWARDS: Who's there you? You who? 
VALENTINO_STOLL: summer blowout
DAVE_KIMURA: If you've never seen frozen, which I have three girls, so they've all seen it hundreds of times. Yes, the greatest joke ever 
STEVE_EDWARDS: I can remember that because at the time frozen came out my daughter was in middle school and I can still remember all through that year. They would you know at their graduation parties they're Belting out the songs, you know frozen Everything was frozen. Okay. Thank you. Can we move on?
DAVE_KIMURA: All right. Well, Dan and Steve, thank you so much for coming on. If you all want to find some more content from Dennis Eve, head over to the JavaScript Jabber show from Top End Devs and you can find them there. 
DAN_SHAPPIR: Yeah, for sure. We would love to have you on our show as well. And it's been a pleasure being your guest. So thank you for having a lot of fun. 
VALENTINO_STOLL: Yeah, thanks for coming on. This was great.