Steve (00:01.363)
Hello everybody, welcome back to an exciting episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mime, excuse me, a stumbling mime, but I'm still your host. And with me today is our new, my new co-host, Cody Bontacue, coming from cold and dreary Hawaii. How you doing, Cody?
Cody Bontecou (00:24.21)
Hey Steve, hey everyone, happy to be here.
Steve (00:28.395)
Yes, today is just Cody and I, no guest, but we do have quite a lineup of guests coming up here in the next few weeks and I'll talk about those at the end. And before we get into our topics of the day, I'd also like to welcome the studio audience again.
Thank you.
Steve (00:52.031)
Uh oh.
Steve (01:02.675)
Woohoo! Okay, sorry, Mike.
I know, I know. You guys can stop now, it's okay. I actually zoomed in on my browser a little too quick there and the square disappeared to turn them off. Anyway, it's amazing how they always sound exactly the same every time they come in, don't they? They practiced a long time for that. So, topics today are Nuxed, what are we calling? Server, Nuxed Server components and some routing goodies for view.
So first off, we have an article here from Mr. Daniel Rowe. If you're in the NUX community, I'm sure you're aware of his name. I think he's sort of what you would say is the tallest hog in the trough at NUX these days. The big guy, big man on campus. And so he carries a lot of weight. And ironically enough, we are going to have him on here in Views on View in a couple of weeks to catch us up on all things NUX.
So we can talk about this and other things. But the blog post that we're discussing today is a guide to Next Server Components. And it's published, he put it out July 24th. So as of this writing just pretty recently, or excuse me, this recording pretty recently. So anyway, I'm gonna pass this off to Cody to so he can elucidate on the details of Next Server Components.
Cody Bontecou (02:30.626)
Hey, yeah, so Daniel posted this article two days ago and he clearly stated that this is going to be like a live document. He's gonna be actively updating it as more questions come out as people are interested further in this. So we'll post this in the show notes so you can follow along. He also lists the roadmap as well as...
possible new features that are in like actually in review within PRS right now, which is super fun to watch So I'm sure a lot of you have heard about server components through react they've been getting a lot of Interests a lot of criticism a lot of discussion around this big change recently. I think it was in I Think it came out with next 13
But little do they know, Nuxt has actually had server components even before React. So Nuxt is ahead of the game there. And some of the key points that Daniel mentions in this article, and I'll just mention the key benefits. One, server components allow you to extract logic out of your client-side bundle. And so...
Daniel talks about how you can move some of your server components, sorry, some of your client-side components into the server. And this is really good for things that don't need to be hydrated or tracked by view.
things that don't need to be rerun on the client. And I think a lot of you may notice a similarity. Astro is very similar to this, and I'm sure Steve has more things to talk about Astro.
Cody Bontecou (04:22.526)
And so one thing that Daniel mentions here is that Astro follows something called the island architecture. And so you have this static site with individual dynamic islands within the site. And these dynamic islands handle a bit more of your dynamic, you know, like content that needs to change constantly. Whereas Nux kind of took the opposite approach where the Nux app itself is
and it embeds static islands within the application. And honestly, I don't have a huge understanding about that, but that is fascinating, and I would love to hear Steve's voice on that, as well as Daniel's in the future of, you know, what are the pros and cons of those two approaches, and yeah, what we're going to be seeing moving forward.
Steve (05:16.127)
Well, I can give you a little bit of it, but we've had Fred Schott on here before. He's the main guy at Astro. And the idea with Astro is it was initially out of the box for static sites. So you're going to generate your static site. But the idea is that all of your content is basically server rendered or it's generated and then.
you query with just some JavaScript queries in your components or you can have, you know, several files that are queried in your back end. I used it with a remote content, a headless CMS Prismic. But then on the front side, the idea is that you're limiting the amount of JavaScript that you're downloading to the browser. But.
The idea is that for those things that you do need some interaction for, some interactivity for, on the front end, you can just plug in one of your components of Svelte, React, Vue, etc. And that JavaScript is only used in there and then, you know, is surrounded by all the stuff that's coming from the backend. Now they do have some server-side rendering capabilities now.
Cody Bontecou (06:20.685)
Mm-hmm.
Steve (06:32.339)
Those are fairly recent, I don't remember, because it was beta for a while, and now it's marked as.
It's not marked as beta in their documentation anymore. So they do have that capability as well. But that's what the idea of the islands is, is basically that everything is coming from the back end. Then if you do need some JavaScript, you can drop in your component of choice from your framework of choice, just where you need it. So, you know, as compared to something like a straight view component that takes over the entire page.
Cody Bontecou (07:04.786)
Yeah, no, it's fascinating. And the more I read about this, the more I actually want to implement it in my own personal projects. I think a lot of my projects just have, unknowingly, a lot of JavaScript, but I tend to write very static sites that need very little amounts of state management.
And it's actually kind of neat on this blog post, if you, he has a little button on the bottom that says, show server component outlines. And he actually outlines every aspect of the application that was rendered by the server. And then, you know, also shows non-server rendered aspects of the app.
And so one aspect, one non-server aspect is like mentions. And I'm actually curious. I'd probably look at a source code with the mentions is, but I imagine that's some sort of like, I don't know, is that like a rest end, is that a rest end point? And I guess that's what I'm not quite wrapping my head around is how much of this is.
Like trying to think of like a traditional just like rest back end. Is it just hitting that back end once and then you're good? Or is that, am I just totally missing the point there?
Steve (08:26.991)
reading through this I'm not sure myself. To be honest it seems like there's you know in reading through this blog post and thinking of you know the stuff I like to use like inertia and looking at server-side render from Astro it all seems to be just slightly different flavors of achieving the same goal.
Cody Bontecou (08:29.556)
Yeah.
Cody Bontecou (08:46.878)
Yeah, I mean, just like thinking through it, like I see this one, his footer component, for example, and he has like this list, this array of links and this like for loop syntax. And so my understanding is, you know, you're basically the server or node, or I think in Nuxt's case, it's Nitro, is doing all of that computation and then just sending a static HTML, I guess, component. And there's probably some magic that's combining all of that HTML. And then by it,
being server-based, there is no additional client-side hydration taking place. So my guess is maybe the client-side just kind of forgets about it after it's been rendered and doesn't have to...
continue monitoring it and hydrating it on other areas of data change. So for example, if this mentions does update, if there's some, I don't know, web hook or some sort of like dynamic aspect to it, it's not going to then re-render other areas of the application. But again, this is why I would love to talk to Daniel and kind of just like dig deeper.
into these concepts and I'm definitely gonna pull this into a personal project and kind of explore further because I do see a lot of benefit if you can just kind of server render it into just pure HTML and remove all of that client-side JavaScript there's a lot of benefit there.
Steve (10:16.703)
Yeah, I think, I mean, the one thing worth mentioning here, I don't think we mentioned is the naming convention and how it differentiates you between a server and a front-side component. So that it's, all you have to do is instead of a something.view, you do, you know, my component.server.view. And apparently Nitro reads that prefix and runs it server-side versus, you know, mounting it on the front-side in the browser.
Cody Bontecou (10:47.262)
Right, right, exactly, super simple. And then you can also do the other side of doing a component name dot client dot view. And then that's just a client-side component.
Which in my perspective, you know, comparing to the React world where they use client or I guess the other one is use, maybe use app, I actually don't remember. Up in like a little comment at the top of the application, I much prefer the file naming syntax here in Nuxt. I think that was a great decision.
and looks very clean and it's very, you don't have to actually look into the application, the component itself to recognize if it's server or client. One other benefit, another benefit that Daniel mentions here is that server components ensure that privileged code runs securely.
And so he mentions that if your logic requires access to a database or you need some private keys, the server component, it can be a great solution here as well. But he also mentions. Okay.
Sorry. But he also mentions using, you could use Nitro here. And so again, that's kind of where I've gotten disconnected is I assume Nitro was doing some of this server aspect. I assume Nitro was the Nuxt server. But again, for my understanding in these server rendered components, you can do direct component to database interactions, which is fascinating. Instead of having that weird little
Cody Bontecou (12:29.642)
you know, HTTP requests or your fetch request in your front end to do it into your back end, et cetera, et cetera. You can have all of those UI elements interacting directly with your database, which makes a lot of sense. And I'm just curious, like where are the limitations here? You know, is there limitations in the data? Like what happens when the data updates? Like, why don't we all just do this? Or is that the, is that where we're moving?
Steve (12:41.663)
Mm-hmm.
Steve (12:45.478)
Oh yeah.
Steve (13:01.235)
Yeah, I mean, you know, this is a topic we've beat to death before, whether it's here JavaScript, Java.
Cody Bontecou (13:08.087)
Mm-hmm.
Steve (13:11.175)
But...
Steve (13:16.37)
Um.
But yeah, you don't want to, it used to be, you know, everything was a monolith, you know, I think back to initial WordPress, Drupal, Joomla, take your pick, right? Everything was a monolith, so you had your...
Cody Bontecou (13:27.17)
Mm-hmm.
Steve (13:36.319)
What am I thinking here? Everything was one big thing. You had to have the whole stack. Then you started getting the mean stack, Mongo Express, Angular node. And then the MERN stack, and pretty soon you had all these different pieces that you could glue together. And you had your frontend and your backend. In the middle of that, then you had Angular came in, and then React and Vue, and the different variations where you didn't need a backend. You could just query everything from your frontend and download your JavaScript.
and query from there, and now you see the pendulum swimming back to doing everything on the server side because, you know, you're... I think to me the big reason is...
Steve (14:25.051)
Resource, you're going to have a heck of a lot more resources running queries and API calls and stuff from a server. It's going to be a heck of a lot more powerful than what you can run in a browser, right? Or even just making the API calls so if you can use your server resources more efficiently like that, then you're going to be that much quicker than leaner. So, you know, that's the...
Cody Bontecou (14:35.19)
Mm-hmm.
Steve (14:52.531)
you know, same process we've been seeing over the past few years, like everything was, oh, yeah, we can do all it on JavaScript in the front end, don't need a backend. And I was like, well, maybe not so much. Let's move it all to the backend, you know, where it's more efficient and only do what we need to on the front end and only download as much JavaScript as we need on the front end. So, you know, that's, that's my little rant. That's how I see it moving at least.
Cody Bontecou (15:12.083)
Yeah.
Cody Bontecou (15:16.81)
Yeah, and that is curious. You know, I do love the idea of, you know, having the client manage it. But, but at the same time, it, it becomes a lot more accessible when you, when you place it on the backend, at least in my, my mind, right? Like you have these mega servers out there or whatever, you know, doing all the work sending over just the bare minimum so that people on their mobile devices all over the world can, can consume and enjoy this content. Um,
And I would love to like, that could be an interesting topic is just like, kind of studying the history behind this shift over the last 10 or 20 years, however long it's been. Is it where we just hitting a moment in time where like resources, we just thought with these new powerful phones, you know, we could do whatever we want on the client side.
I'm curious why we're shifting back and forth so often. Or is that just the curse of the JavaScript world? But.
Steve (16:18.975)
Well, I don't see it as initially going back and forth. Like I said, it was, you went, you know, if you think about the initial PHP, maybe Java, you know, early 2000s, where it was, you know, monolith, everything's on the backend, you've got your PHP templates or whatever you're using on the front end, and then you swing over to all JavaScript, right? And then we're swinging back, but not quite so far as.
Cody Bontecou (16:40.523)
Mm-hmm.
Steve (16:46.563)
it was to start out with where it's not all a monolith. You can still piece things together and you can do it in such a way that you're only using as much JavaScript as needed. So that's where I see it. And so yeah, in reading through this post and talking about Nuxt server components, it's basically, you know, Nuxt doing the same thing you know, as other...
Cody Bontecou (16:56.19)
Yeah.
Steve (17:13.659)
you know, setups, do as much here's let's do it all in the server and then only do as much as we need in JavaScript on the front end. And here's some good use cases for it. Now for what it's worth, he does mention that this is different from, uh, react server components. Uh, so he says this is an entirely different approach to rendering server components, which is often linked to streaming responses from server to client, so, uh, not being a react guy. I,
At the same time, I can see what he's talking about. So.
Cody Bontecou (17:48.49)
Yeah, I'm curious. I mean, when I hear streaming, I think like WebSockets or something, like they create this open connection between the server and the client. And I am curious, you know, if he could expand on this entirely different approach, or is that what he means with this static island dynamic Nuxtap approach?
Steve (17:58.941)
Right.
Cody Bontecou (18:12.822)
But yeah, very excited. I'm very happy he wrote this article. It really just kind of laid down the map on some of this stuff very precisely. I knew it was around, but it really wasn't well documented. And so...
This is going to be a great starting point to moving forward. One thing I do really want to mention, though, that I think is fascinating is the first point on his roadmap is he mentions remote sources. It will be possible soon to load server components from other websites, enabling you to create microservices that render components which you can use in different websites.
And so like, yeah, I see, I see your confusion on your face. I I'm curious what this means. Does this mean I can like hook into someone else's, uh, next component? Can I just say like, give me your Stripe payment system and just build all, throw in my API keys and we're good to go. Um, can I just, what, what does this mean? Is this like a HTTP request, but to a, to a UI component? Um.
I have no idea. And I was gonna look at the PR, but it's honestly just one page difference, and one file is changing. And I'll have to read it a bit further, but I'm fascinated. It looks like there's a source, or the URL can be a source, or a potential actual URL.
Cody Bontecou (19:55.342)
So that should be cool. I don't know. It's just like mind bending to think about that. If I can actually hook into external.
sources and that's kind of like what I think is really neat about just this whole component architecture client-side or server-side is how easy it is to utilize a lot of this logic between projects you know hooking into something like Vutify whatever I can just easily put in what looks like HTML and I have an amazing application very quickly so
But yeah, that's about all I have for this article. But is there anything else you'd like to mention, Steve?
Steve (20:40.483)
No, not really. It looks like there's PR, so the remote sources. There is APR looking at.
Cody Bontecou (20:46.54)
Yep.
Steve (20:51.315)
Sounds interesting, it's like you can make a service available on your site that somebody else can access or something like that, which would be interesting. I have to ask Daniel, I don't understand how that fits in with Nuxt specifically as compared to maybe just making a generic API endpoint. Maybe there's some custom rendering or something you can do in your microservice.
Cody Bontecou (21:06.411)
Yes.
Cody Bontecou (21:14.214)
Right, I mean like if you looking at this PR there's just like this source prop into your next Island and if you look at this actual source Basically if a source is provided it generates a new URL Otherwise it just uses like your local Prop or local component and
Yeah, I don't know what more you can do there, but am I hooking into somebody else's database? What sort of limitations, what sort of things are there? Because there's not much code change taking place here. So I'm thinking maybe I missed something, but I could be wrong, it might be that simple.
Steve (21:57.119)
Yeah, yeah, it is, for sure. All right, well, we will have to wait and talk to Daniel here in a couple of weeks, and I'm sure he can give us all of the glory details.
Cody Bontecou (21:59.839)
Yeah.
Cody Bontecou (22:06.57)
Yeah, looking forward to it. I'm gonna, I'll definitely have some questions lined up as well as some more personal experience digging into this now that we have a wonderful post by him. So thank you, Daniel. But yeah, one more thing I wanted to mention this post or this podcast is,
I'm sure many of you are subscribed to the LearnView YouTube channel and he posted recently within the last week a YouTube video called They Just Fixed View Router and highly recommend giving it a watch it's only two minutes long but he digs into what's called Unplugin View Router. It's a new
It's a new package created by Eduardo. He also goes by Postfaw, P-O-S-V-A, sorry if I pronounced that wrong, Eduardo. But he is the lead dev of, I believe he's the lead dev of the original Vue router package. And now he's kind of created this new unplugged Vue router package, which is, the slogan is, next gen file-based typed routing for Vue router.
And it's very simple, you just basically cut out your original view router import within your router file. And you import the exact same thing, but you just extend it with the slash auto. And this now makes it so you don't have to pass your routes. The plugin just auto writes it for you, very similar to Nuxt. It basically gives your view apps the Nuxt file-based routing, which...
is a huge plus for me.
Steve (23:57.755)
Yeah, I know that's one of the features that I have seen used or appreciated in Nuxt where some people have really just needed view, but they use Nuxt because of stuff like that where it had the file-based routing and you weren't having to manually configure your JSON files with your routes and associated components and so on. And that's, you know, Astro goes that way and other...
tools use that. So to me it's sort of a logical improvement.
Cody Bontecou (24:33.382)
Oh yeah, no doubt. In fact, that was, you know, I originally started with Vue, but the routing aspect is actually very confusing for me. I struggled throughout my head around it. And so Nuxt really was kind of that crutch to help me pick up Vue, because it was just one more like major aspect of the application that I just didn't have to think about. You know, and so.
But I do want to mention, while this does provide that simplicity of page-based routing or file-based routing, it still has fully customizable features like the traditional view router. And so it can help abstract away some of that complexity if you don't want it, but it's still there if you do.
which is kind of beautiful, frankly. I love how the Vue team does that. A lot of magic, but also great documentation if you want to dig in. But another benefit of this plugin is it's typed. And so when you use your use route composable, it now, within your strings, you'll do a use route composable and you pass in a string for which...
route you may be managing where you want to get the params from and it provides auto complete. So you put in the string and all of a sudden you see all potential routes, all potential pages that you want to be working with.
And then alongside that, you know, the route object that's returned from this composable is also typed. So, say you want to do a route dot params and you're passing an ID, you know, that dot ID is auto completed, it shows you, you know, that TypeScript magic of, um, what values are within this object, which can be very
Steve (26:28.847)
It's types everywhere, it's crazy.
Cody Bontecou (26:31.498)
Oh man, you gotta love TypeScript. I don't like writing the TypeScript that these guys do, that the team does, but I love utilizing the benefits, so thank you. But yeah, and obviously there's one more, router.push also provides auto complete. So I imagine this is probably gonna get sucked into view. In fact, I'm curious why it hasn't yet, why it's kind of been the separate unplug in.
a repo, but it's probably similar to Pinyo, where it just kind of took over Vuex, right? I imagine this will be the same.
Steve (27:12.515)
Yeah, that's a cool little plug-in. I wonder if they end up importing that or integrating it into core router capabilities in V3.
Cody Bontecou (27:21.547)
Right.
Cody Bontecou (27:25.602)
Great, yeah.
Steve (27:25.607)
that would make sense, do it as some sort of configurable option or something like that.
Cody Bontecou (27:29.886)
Right, just some, yep, exactly, some config. But yeah, looking forward to playing with that as well. Honestly, I'm more of a Nuxt guy. I've never really gone back to the view, to the view land outside of Nuxt, but I feel like I probably should. I don't know, with all this server, server stuff going on, I haven't figured out why, why to go back to just plain old view.
Steve (27:57.043)
Yeah, I've been, you know, I've, being as a PHP guy, I think I actually did start to learn Node one time, take a Udemy course from X-Mail and Schwarzmiller on it, but never really got into using Node. And then once I discovered Laravel and being familiar with PHP, that's just really made it a lot, the awesomeness of Laravel to amazing what that framework does for you.
That's just sort of been my back-end tool of choice, especially with Inertia, and being able to use it so seamlessly with Vue. For a dynamic database apps, where it's just sort of a management tool where you don't give a rip about SEO and server-side rendering and all that stuff, it's just data management. To me, for my skill set, that's a perfect choice. For someone who's more of a node background, something like this.
Cody Bontecou (28:28.439)
Yeah.
Cody Bontecou (28:42.915)
Mm-hmm.
Steve (28:52.729)
you know server-side components with Nuxt would be ideal I think you know so
Cody Bontecou (28:57.994)
Yeah, I totally get it. My only issue with server-side NUX.
is I don't really understand serverless architecture. And so I'm always afraid of shipping something through Vercell or Netlify, utilizing these server side server routes and API routes within my like Nitro API. And I'm afraid it's gonna like, all of a sudden cost me a lot of money, right? With like a traditional backend, it's easy to kind of...
you know, separate the two and have a comfortable management of one over the other. But I do believe there is some magic, it seems with like Nuxt's interaction with, with the server. And so even in times where I don't think I'm utilizing the server, it turns out I am. And all of a sudden it's like, Oh, Whoa, like I just ran out of my free plan or something, hitting an end point that's just built into Nuxt.
And so that is an issue I have, and I do still enjoy the traditional just like Python or PHP, your separated backend. But the developer experience of just having it all in one project is amazing. And so I do, I really enjoy just writing my full stack app in Nuxt. But there is...
I would be afraid to ship it to a million people because I don't quite understand all the bits and pieces of it.
Steve (30:31.151)
Yeah, yeah, as it's fairly new, I'm sure it's going to take some getting used to. I have a feeling though, once you were to get your head around it, it would make sense and you'd be able to just sort of, you know, use that with what you already know of next.
Cody Bontecou (30:45.546)
Yep, no, for sure. For sure. Well, cool. Should we move on to our picks?
Steve (30:53.519)
Let us move on to picks. So picks are part of the show where we get to talk about other things other than tech or view or NUX, but we can if we want to. So I usually have my specialties for the picks, but I'll let Cody go first today.
Cody Bontecou (30:56.134)
Right.
Cody Bontecou (31:14.282)
Yeah, I would love to. So mine is semi-tech related, not code related, but I'm not sure, I'm curious if you've ever heard of Arc. So it's a web browser.
Steve (31:26.311)
Yes, I have. It's sort of a developer friendly browser. Is that right?
Cody Bontecou (31:30.83)
Kind of, I mean, actually I wouldn't say it's like super heavy in the developer experience, but it is like very key bind heavy and it has this neat like zap feature where you can zap away basically just permanently delete aspects of web pages, heavily configure them to your liking and it saves that way.
But it just came out yesterday to everyone. And so I've been using it for a couple of days. It used to be invite only, but yesterday was its official like V1 release. And I just really love it because it's very keybind focused and very, I'm a big fan of like Zen mode programming, right? Just minimal toolbars, minimal little widgets and things poking out. And this has, yeah.
Steve (32:20.443)
Yeah, to distract you, right? Hey, let me go look at this page, look at this site. You wanna hide that.
Cody Bontecou (32:26.706)
Right, you know, like, let me just cover an eighth of the screen with my URL bar. You know, I'm like, I don't like that. And so, um, so that's just kind of built into arc browser. In fact, like the URL bar is a very small aspect of it. It's very, um, if you use spotlight or something like raycast where you'll like, you know, hit, so in, in art, you'll do a command T like tab, and that opens up your URL bar, but it also opens up. Um,
all your commands. So one like built-in command is just like capture and I can hit capture or capture full page and so there's like this really unique like screenshot feature built in. There's also
like a notes feature. So I can just create a note right there in the web browser and then if I really want to, they'll host it and create a shareable link for me for that note as well. Which is, which is amazing. Obviously, you know, it is V1 so it is missing some features. Doesn't work on Windows is one. Their mobile browser is pretty kind of weak, in my opinion.
And there are issues like the notes, for example, it's not exportable. Like I would love to be able to write a note in my browser, export it to markdown, send it up on my blog, for example. Um, right now that's not, that's not possible. Even though they do support markdown notes, the actual export feature is not supported, but.
You know, they do have a person on Twitter and they take private messages. So I just send them all my future requests and they say they write it down. So we'll see. We'll see where it is in the next couple of months, but so far I'm loving it. Honestly, it's very privacy focused and so I'm, I'm about ready to uninstall Chrome and just go full-time arc.
Steve (34:18.363)
All right, is that your pic?
Cody Bontecou (34:21.517)
That's my pick. Arc browser V1 is out. Highly recommend trying it.
Steve (34:26.775)
Okay, so with that we will move on to my picks. Let's see, there's one thing I just saw that was interesting. I guess just sort of historical note for somebody who was around since my time. I just saw a blog post that Sinead O'Connor had died. If you were live and listening to music back in the late 80s, you knew Sinead O'Connor. She was Irish, I think, and she always had a shaved head.
She had a song called Nothing Could Perish To You that was just, I think it ruled the world for I don't know how long. Only 56, so she's only a year older than me. And she died and they're not saying why which is, it's always a bummer to see something like that. On the lighter side of things, it is time for the dad jokes of the week while I get my crowd together here ready. So
Cody Bontecou (35:01.206)
Nice.
Steve (35:22.919)
You know, one of the common lines about Star Wars is the humorless note that stormtroopers shoot a lot but they never really hit much. So along those lines, what is the favorite store for stormtroopers to shop at?
Steve (35:43.663)
It's not target, it's the one next to target.
Steve (35:50.727)
Right? So, the other night, my neighbor knocked on my door at 2 a.m. Really? Just to tell me that he couldn't sleep. I said, well, it's your lucky day. We got a party going on here. So come on in.
Steve (36:09.608)
And then I had an appointment next week with a psychic. I was trying to get some help from a psychic. But unfortunately she called me to tell me that I wouldn't be able to make it.
Cody Bontecou (36:24.527)
nice.
Steve (36:25.999)
So that's better than my old psychic that I had, you know, I went and knocked on her door and she said, Who is it? And so I left. Because he's obviously not a psychic if she didn't know who it was. Right? So, anyway, that's my new and improved psychic. Actually, you can see things. Just kidding, I'm not into psychics. Just a joke, just to clarify. Okay, so with that...
Cody Bontecou (36:37.687)
Right.
Steve (36:49.255)
We will wrap up this episode of Views on View. Like to point out who we got coming up in the next few weeks. In a couple of weeks we have Daniel Rowe of Nuxtfame. We also have John Leder, who is the main guy with Viewtify. So we'll talk about Viewtify 3 and where things stand. And then a couple, I forget, it's Jacob Andrzejewski.
We've talked to him before on the podcast coming live from Poland, right, Cody, if I remember correctly? Right. Marcus Oberlinner. I think most people know that name in the views world. I know I've seen him around.
Cody Bontecou (37:21.166)
I believe so. Yeah. I believe so.
Cody Bontecou (37:31.446)
Yeah.
Steve (37:31.567)
And then next week, Alexander Gekkov, a friend of Cody's. Thank you, Cody. So those are people you can look for other than just me and Cody in the next few weeks. That could be good or bad, I guess. So with that, we'll wrap it up. Thanks for coming on, Cody. Look, it's nice to have you here on the show with me.
Cody Bontecou (37:37.153)
Yeah.
Cody Bontecou (37:45.11)
Hehehe
Cody Bontecou (37:52.97)
Yeah, anytime, happy to be here. Loving all the new stuff coming out, so it's a fun space.
Steve (37:55.443)
And right on. And we'll wrap up this episode. So we'll talk to you next time on Views on View.
Cody Bontecou (38:03.502)
Cool.