Speaker 1: Hello, everybody, Welcome to another exciting episode of JavaScript Jabber.
Speaker 1: I am Steve Edwards, the host with the face for
Speaker 1: radio and the voice for being a mine. But I'm
Speaker 1: still your host, at least for today. Chuck has out
Speaker 1: had some work to do. Dan he is on vacation,
Speaker 1: so he's taken some time off. So it's me and
Speaker 1: on the panel. I have mister A j O'Neil. How
Speaker 1: you doing, aj.
Speaker 2: I'm doing fine, flipping fantastic. No, yo yo yo.
Speaker 1: Yo y oh? Did you on the back end? Oh?
Speaker 1: Back end?
Speaker 2: Sorry, you asked me a question, So okay, I give
Speaker 2: you the answer, and then I added the yo yo
Speaker 2: yo yo yo yo, coming at you live from my goodness.
Speaker 2: Isn't the weather heavenly today?
Speaker 1: Yes? It is here too. It's awesome. I was thinking
Speaker 1: the fall was coming way too early last week, but
Speaker 1: that's warming up. Supposed to be ninety here in Portland tomorrow.
Speaker 1: We're looking at some sunny sky and some good weather.
Speaker 2: So we did a drive through the mountains yesterday with
Speaker 2: the kiddos.
Speaker 1: Hey, Jay, see the fall colors.
Speaker 2: Yeah, it was wonderful.
Speaker 1: Yeah, okay, it is after the twenty first, so I
Speaker 1: guess we can start calling it fall now, can't we?
Speaker 1: Although here we tend to have really nice September and
Speaker 1: October Indian summer they call it, so that's always nice. Anyway,
Speaker 1: as we blaberon, let's welcome our guests, mister Daniel Kelly.
Speaker 1: How you doing, Daniel, Hey, Steve doing great?
Speaker 3: Great to be here.
Speaker 1: So Daniel is a prominent member of the view JS community,
Speaker 1: and so since I don't do the views on view
Speaker 1: podcast anymore, I like to bring in some view JS
Speaker 1: content into JavaScript jabber every once in a while, and
Speaker 1: this is my chance.
Speaker 3: Yeah, get a rep view here.
Speaker 1: Yes, that's right. We need a good view of what's
Speaker 1: going on. Sorry, I missed my dang it, I missed
Speaker 1: my sound effect. I'll do it. Delay there we go,
Speaker 1: thank you. Okay. So, first of all, Daniel, why don't
Speaker 1: you just give us an intro on who you are
Speaker 1: and why you're famous and we'll go from there.
Speaker 3: Sure. So, I am the lead instructor over at view School.
Speaker 3: We're one of the primary places you can go to
Speaker 3: learn view JS, whether you're a beginner or you know,
Speaker 3: even in a more advanced view person. We've got all
Speaker 3: kinds of tutorials available for everyone. So I've been working
Speaker 3: with view School for almost four years now, Has it
Speaker 3: really been that long? Yeah, Google, I think.
Speaker 1: Yeah.
Speaker 3: So we also run in the in the conference kind
Speaker 3: of circuit there. I go to conferences all the time
Speaker 3: with view School. We put on a few virtual conferences
Speaker 3: and also recently got into the certification space, so we
Speaker 3: worked with Evan you to create an official view Jess
Speaker 3: certificate so you can take an exam, you know, show
Speaker 3: potential employers. I know my stuff, right, So yeah, that's
Speaker 3: kind of what I do on the day to day
Speaker 3: these days.
Speaker 1: So let's talk about that for a minute. I know,
Speaker 1: way back when before I got into web development, I
Speaker 1: was doing software and I got into doing some network certifications.
Speaker 1: So if you're looking at network certifications for instance, I
Speaker 1: was doing on one. Uh this is Windows. This is
Speaker 1: early days of Linux. I don't even know if Linx
Speaker 1: was out yet, but like Windows NTI network certifications. You know,
Speaker 1: there's a plus certifications, and I know that it's seen
Speaker 1: as a way to say, hey, I really know what
Speaker 1: I'm talking about. I can remember when I was in
Speaker 1: the drouple world. You know, there was always issue when
Speaker 1: you know, when hiring a developer to do a druple
Speaker 1: site for you. How do you know that they know
Speaker 1: their stuff? And I know that up Drupal has come
Speaker 1: up with certification test if I remember, I haven't looked
Speaker 1: in a while. So you know, view development, any type
Speaker 1: of development can cover a wide array of topics, you know, absolutely,
Speaker 1: So I'm just curious this first chance I've had to
Speaker 1: talk to somebody about this. Can you talk about what's
Speaker 1: involved in generating a certification test? And obviously you got
Speaker 1: the input from the guy who created you, which is
Speaker 1: you can't get much lower level than that speak right.
Speaker 3: We're very happy about that for sure.
Speaker 1: Right, and then so and then what does it cover?
Speaker 1: What are the main areas?
Speaker 3: So we've got yeah, we've got it really focuses on
Speaker 3: like core VIEWJSS, right, and we have two different levels
Speaker 3: of the certification. So there's like a mid level or
Speaker 3: just kind of regular level developer short and then there's
Speaker 3: the senior level developer certification. And so at the at
Speaker 3: level one, we're basically testing, Hey, do you know just
Speaker 3: like the basics of you? Right, can you create a component?
Speaker 3: Do you know how props and emits work? Do you
Speaker 3: know how to you know how to start a view application?
Speaker 3: Kind of basic things like that, and the way we
Speaker 3: test you on that is we provide multiple choice questions
Speaker 3: at the beginning of the exam and then we provide
Speaker 3: two different coding challenges that you have to complete to
Speaker 3: build some kind of some kind of little app right,
Speaker 3: So it's fairly in depth in terms of what you
Speaker 3: actually have to do to pass the exam. I mean,
Speaker 3: if you can't create this, if you can't complete the
Speaker 3: coding challenge and actually write the code for yourself, you're
Speaker 3: not going to pass. And then at the senior level,
Speaker 3: it's the same structure. It's multiple choice questions and two
Speaker 3: different coding challenges, but the topics are a little bit
Speaker 3: more advanced, things like using Typescript with view, things like
Speaker 3: writing test for your view components, things like a few
Speaker 3: more advanced things that are a little less used but
Speaker 3: can be very useful for creating you know, intuitive APIs
Speaker 3: for your components, things like provide inject for example. So yeah,
Speaker 3: it's it's an interesting dynamic and we've had a lot
Speaker 3: of good feedback from people. One of my favorite things
Speaker 3: to share is actually we have a boot camp that
Speaker 3: goes along with the certification as well. It's a three
Speaker 3: day boot camp. It's a virtual thing, right, but it's
Speaker 3: basically me or a colleague of mine doing a just
Speaker 3: an educational style boot camp thing and people can ask
Speaker 3: questions and we go over all the different topics that
Speaker 3: are on the exam and teach the concepts and so on.
Speaker 3: But I actually had one guy who works on a
Speaker 3: very popular UI library in the View community who attended.
Speaker 3: You're like, why would he attend? Like he knows View right,
Speaker 3: and he came out telling me he learned stuff. So
Speaker 3: I'd really like to talk about that really really makes
Speaker 3: me feel good.
Speaker 1: So I assume that with I mean, there's a huge
Speaker 1: number of apps ot out there and still in View two.
Speaker 1: I mean, I will work on a very large one
Speaker 1: every day. And you know V three has been out
Speaker 1: for is it two years now? I want to say
Speaker 1: twenty twenty.
Speaker 3: Actually I believe I think it's been almost four years now.
Speaker 1: That isn't really wow anyway, Okay, so you have, you know,
Speaker 1: a lot of U two step out the View three
Speaker 1: is the latest and greatest. So are there cerif case
Speaker 1: to test for both? Is everything focused on View three?
Speaker 3: That's a great question. It is focused on View three.
Speaker 3: All of our exams focus on the current level and
Speaker 3: as soon as the as soon as the current latest
Speaker 3: is has changed to you know, increment to the next thing,
Speaker 3: then we will have new exam material for that next level.
Speaker 3: That's kind of our strategy there. But yeah, it's all
Speaker 3: of you three. It does focus on the composition API
Speaker 3: as opposed to the options API because that is the
Speaker 3: recommendation from the VJs stocks now and that's the direction
Speaker 3: Evan wanted to take it while we were developing it.
Speaker 1: So yeah, okay, so how many any ballpark figure on
Speaker 1: how many people have been taken it so far?
Speaker 3: Oh? How many have taken it? That's a really great question.
Speaker 3: I couldn't give you an exact number. I know it's
Speaker 3: I mean, we're literally getting people taking it every day.
Speaker 3: Their exams come in every day for the past year.
Speaker 3: So do the math on that. I'm not sure exactly
Speaker 3: how many.
Speaker 1: But yeah, so is this run through view school? Is
Speaker 1: that you school that's running this certification? More of a
Speaker 1: open source type thing, I guess for lack of a
Speaker 1: better term.
Speaker 3: Right, we uh, it is our team that produces the
Speaker 3: content along with third parties like Evan, but the brand
Speaker 3: is called Certificates dot dev. So the website is certificates
Speaker 3: dot dev and we had we started out with just
Speaker 3: the view exam, but we found that that was so
Speaker 3: meaningful to people that we pivoted to also not pivoted.
Speaker 3: We expanded to also do other certifications as well. So
Speaker 3: now we also offer an Angular certification. We're actually launching
Speaker 3: tomorrow a JavaScript certification, a more general JavaScript certification, and
Speaker 3: we offer a next certification as well.
Speaker 1: M okay yea, I'll put the link up here in
Speaker 1: the little banner here for a second. Angler. So are
Speaker 1: you guys you have somebody with Angular expertise that's that's
Speaker 1: doing that one?
Speaker 3: We do absolutely. So. We we partnered with a guy
Speaker 3: named Alan. Oh, he's gonna kill me because I I'm
Speaker 3: gonna butcher. His last name Gerard I think it is. Anyways,
Speaker 3: he had an a give their certification that he's been
Speaker 3: working on for years and he wanted to partner with
Speaker 3: us just to make his processes a little bit easier
Speaker 3: and so on. So he is definitely an expert with
Speaker 3: that kind of material and provided a lot of that.
Speaker 3: It was just a matter of, you know, changing it
Speaker 3: up a little bit to fit our standards in our
Speaker 3: platform requirements.
Speaker 1: Okay, Yeah, so here's the view and interesting. So having
Speaker 1: had to administer and take online tests and scenarios and
Speaker 1: stuff out of curiosity, how you mentioned that there's some
Speaker 1: multiple guests excuse me, multiple choice questions throughout the test,
Speaker 1: and then there's some coding challenges and things. So how
Speaker 1: has that done? Is that like a clonable repo that
Speaker 1: you can do and push back to a repo or
Speaker 1: is it just like an online thing like a hacker
Speaker 1: rank environment or how exactly is that test done?
Speaker 3: So it is all in the browsler. In fact, we're
Speaker 3: pretty what's the word for, we are literally watching you
Speaker 3: during the exam. There's there's this entire proctoring setup. Yeah,
Speaker 3: it's intense, right, there's your camera's on, your screen is
Speaker 3: being monitored, your your mic is on. It's it's monitoring everything.
Speaker 1: A G.
Speaker 3: You want to say something, I.
Speaker 2: Can tell I always bomb those like when the quession
Speaker 2: is on, oh yeah, I bombed with yeah. When the
Speaker 2: pressure is on like that, I forget how to do
Speaker 2: fizz buzz. And oftentimes it seems like in most of
Speaker 2: those situations they're looking for a very specific answer, so
Speaker 2: it's not like, hey, here's a here's a problem that's
Speaker 2: reasonable to have, and then walk us through what are
Speaker 2: you thinking about that? How would you solve it? It's okay,
Speaker 2: so you've got the numbers twelve, twenty seventy to eight
Speaker 2: and four. They're in an array, but they're backwards, they're
Speaker 2: inside of an object, and you need to have uh
Speaker 2: less than oh two lot in like like, so, how
Speaker 2: do you solve this problem? And it's like, uh what, yes,
Speaker 2: and then and then and then like you saw that
Speaker 2: and they're like, well, that's not the solution that we
Speaker 2: have in our bookshet here, so.
Speaker 3: Totally totally yeah, And we we've done a lot of
Speaker 3: work to try to avoid that as much as we
Speaker 3: can while still being uh, you know, you have to
Speaker 3: have the parameters that they work in, and we tried
Speaker 3: to make the coding challenges specifically kind of lifelike things.
Speaker 3: For example, I don't want to give too much away,
Speaker 3: but maybe there's, you know, in the the view one,
Speaker 3: maybe you have to create like a carousel, right that
Speaker 3: has some kind of functionality that requires JavaScript rotating the images,
Speaker 3: you know, blah blah, so on and so forth. So
Speaker 3: we try to make it a fairly realistic thing where
Speaker 3: you understand what the goal is. So so yeah, that
Speaker 3: that's kind of our way of trying to avoid the
Speaker 3: situation you're talking about. But we definitely have found over
Speaker 3: time that we've had little instances exactly like you're talking about,
Speaker 3: and people report would report such things to us, and
Speaker 3: we've been able to work and improve it over time.
Speaker 3: So during the coding challenge portion of the exam, it
Speaker 3: is all in your browser. We embed a stack blitz
Speaker 3: project into the into the platform. I don't know if
Speaker 3: you've heard of stackltz before.
Speaker 1: So last week we just talked to Tomatsolkowski from Stacklitz
Speaker 1: about tutorial Kit and I was about I was about
Speaker 1: to ask you if that was what you were using,
Speaker 1: or maybe it was just embedding stacklits within your in
Speaker 1: the test.
Speaker 3: Yeah, that's right. It is just the classic stacklitz ebed.
Speaker 3: They came out with tutorial Kit. I believe they actually
Speaker 3: launched they announced it, they launched it at JavaScript. I'll shoot,
Speaker 3: I'm getting my conference names mixed up at front end Nation,
Speaker 3: which is a conference FE school puts on an online conference,
Speaker 3: and so yeah, that that wasn't quite out when we
Speaker 3: first released the certification.
Speaker 1: So yes, we do no stack Q. We've had Eric
Speaker 1: Simon's on I think when they first started talking about
Speaker 1: embedding node in the browser a few years ago. So yeah,
Speaker 1: we're familiar with right.
Speaker 3: I'm sure it sounded a little crazy at that point,
Speaker 3: but I love it right.
Speaker 1: Right, right for sure? So cool? What about Okay, so
Speaker 1: people are coming in and you know, taking the certification test,
Speaker 1: say hey, I got the certificate, I can do view.
Speaker 1: Have you seen that being utilized requested in the employment
Speaker 1: community in terms of people who are actually looking for
Speaker 1: view developers. What kind of reception has that been getting.
Speaker 3: Sure, that's an excellent question from my point of view.
Speaker 3: I don't have any I guess case studies per se
Speaker 3: on the employer side of Hey, we were looking for
Speaker 3: a view developer, and we saw some of our applicants
Speaker 3: out of view certification, and so they're the ones we hired. Honestly,
Speaker 3: our marketing team would probably have a ton of that,
Speaker 3: a ton of that valuable stuff, right. But I've definitely
Speaker 3: heard testimonials from view developers themselves who have said, hey,
Speaker 3: I got this in order to help me with the
Speaker 3: job search. Whether it actually ended up helping them long run,
Speaker 3: that's something I don't have the feedback on to be honest.
Speaker 3: But one thing we also I think is a really
Speaker 3: great benefit besides just the higher ability of a developer
Speaker 3: getting the start, we also think another great benefit and
Speaker 3: something we hear actually from people who have taken the
Speaker 3: exam is that they really just want to take it
Speaker 3: to kind of give them the confidence that they're up
Speaker 3: to date and their knowledge. They can kind of feel
Speaker 3: confident that, hey, I have the knowledge it takes to
Speaker 3: be a modern day day view developer, and so that's
Speaker 3: something they self evaluate, right, and we get a lot
Speaker 3: of feedback about that being the case for them.
Speaker 1: So it's yeah, sort of just a measuring tool, I guess,
Speaker 1: or a way to bone up on what's the latest
Speaker 1: and make sure you're learning the right thing and not
Speaker 1: focusing on something it's antiquated that's going to go away.
Speaker 3: Right, exactly right, because because evn't reviewed it all and
Speaker 3: said ahead, this is what you need to know, right
Speaker 3: and uh and yeah, we also we have had a
Speaker 3: few employers I know specifically who you know, have given
Speaker 3: this exam, bought this exam for their employees in order
Speaker 3: to give people raises or you know, elevate their position
Speaker 3: and the team things like that. Right, So that's been
Speaker 3: a successful use case for it.
Speaker 1: Okay, cool, all right, so uh let's talk about we'll
Speaker 1: do well, we'll do some shameless plugs towards the end
Speaker 1: per View school. In terms of View in general. Obviously
Speaker 1: we talked about how you three came out almost four
Speaker 1: years ago or a little over four years ago, and
Speaker 1: I want.
Speaker 3: To google that, Steve, I don't want to tell you
Speaker 3: the wrong thing. View V three When did it come out?
Speaker 3: Let's see twenty two?
Speaker 1: Two years okay? Oh no, it is twenty two, No,
Speaker 1: I'm sorry. It is officially released on September eighteenth, twenty twenty,
Speaker 1: became the default version of February twenty two.
Speaker 3: Yep, yep, that's that's okay, okay.
Speaker 1: So so if you go to view dot the View website,
Speaker 1: it's by default of View three and you got to
Speaker 1: click on a link to go view the V two
Speaker 1: docs with what sort of makes it the default? So
Speaker 1: we're on as we were talking about before, and we're
Speaker 1: on three point five is the current release of View?
Speaker 1: What what's so, what's the latest and greatest coming out
Speaker 1: of view with with the latest releases, Since you're probably
Speaker 1: right on top.
Speaker 3: Of that absolutely, so viewpoint three point three was a
Speaker 3: pretty big one. So with that came define model. I'm
Speaker 3: not sure if you've used define model yet. It's it's
Speaker 3: a really handy kind of wrapper around a common pattern
Speaker 3: for for taking a prop in and then emitting an
Speaker 3: event up whenever the value for that that prop changes.
Speaker 3: So think of like a custom input field, right. You
Speaker 3: bring a prop in that's called model value, and then
Speaker 3: you send an event up called update model value. Right,
Speaker 3: And so define model essentially just lets you skip the
Speaker 3: kind of and dance there and directly alter the prop
Speaker 3: that came in inside of your child component. So whenever
Speaker 3: you actually assign a new value to that prop, you're
Speaker 3: not actually mutating the prop, which would be a no
Speaker 3: no right. Instead, what it's doing under the hood is
Speaker 3: it's emitting update model value for you. So it's just
Speaker 3: a little ergonomic quality of development thing. So that was
Speaker 3: a kind of big addition to three point three. Now
Speaker 3: that's been quite a number of months now since set
Speaker 3: one's been out.
Speaker 1: Can I ask you one question real quick. One of
Speaker 1: the things I used to talk about was component v model,
Speaker 1: which is basically where you you know you have a
Speaker 1: parent and a child and you can do something within
Speaker 1: the child and then admit it back up to the parent,
Speaker 1: you know. And the example I have is one that
Speaker 1: I actually use in an inertia app where I have
Speaker 1: a just like an index listing and a table, and
Speaker 1: then within I do all The table itself is a
Speaker 1: separate component, but the search field that I'm using it
Speaker 1: is in the parent. And because I'm using inertia, I
Speaker 1: got to use a to find URL. So basically in
Speaker 1: my table, I say, you know, I do all my
Speaker 1: stuff or no, I take it back. My route has
Speaker 1: to be defined in the parent. The search field is
Speaker 1: actually in the child, and so I read the child,
Speaker 1: passed it up to the parents what we can call
Speaker 1: the u ur L and that's basically a component V
Speaker 1: model where you can map that real easily and have
Speaker 1: that dynamic field. Is this different or is this an
Speaker 1: improvement on components and the model? Are they just? Are
Speaker 1: they different things?
Speaker 3: It's very similar, So really we are talking about the
Speaker 3: same thing. Like it's the V model on the using
Speaker 3: the V model in the parent on the child component.
Speaker 3: That's exactly what this is supporting. Okay, but it's just
Speaker 3: when you're doing your logic inside the child. It's making
Speaker 3: that logic inside the child a little bit easier to
Speaker 3: reason about in short, less lines.
Speaker 1: Right, okay, so it's yeah, sort of the longest same. Yeah,
Speaker 1: it's really it's an easy way to because it's one
Speaker 1: of the thorning our problems with making everything self contained component,
Speaker 1: you know, trying to so you don't have this huge,
Speaker 1: you know, five hundred line component with everything in it.
Speaker 1: You can break things into reusable components. But then you've
Speaker 1: got to communicate between the parent and the child, and
Speaker 1: that's where it gets gets really sticky and dynamic ways.
Speaker 1: So okay, so sorry to interrupt, so or you were
Speaker 1: going on from there.
Speaker 3: No worries, No worries. So three point four, honestly, I
Speaker 3: have no real recollection of.
Speaker 1: Of what that's a very important release.
Speaker 3: Yeah, truly minor release, right at least in my mind.
Speaker 3: So three in three point five just because it's very
Speaker 3: recent site I am thinking about. Of course, there's always
Speaker 3: performance improvements in every release, right, But also three point
Speaker 3: five brought about a feature called props destructure. So when
Speaker 3: you're working with the Composition API inside of your script
Speaker 3: set up tags, you use a a macro called defined props.
Speaker 3: In order to define your props.
Speaker 1: Right.
Speaker 3: Uh, well, if you wanted to add defaults to your
Speaker 3: to your props, you had to use this weird with
Speaker 3: defaults method kind of wrap the whole defined props call
Speaker 3: and then have a second argument to the with defaults
Speaker 3: be your your actual defaults. So you're kind of like
Speaker 3: declaring your props here, and then you're declaring that the
Speaker 3: defaults for those those props here, and you kind of
Speaker 3: have to, you know, put those keys in twice, and
Speaker 3: it's just kind of weird and cumbersome. And then when
Speaker 3: you're working with your props, you have to say constant
Speaker 3: props equals defined props, and then you're working with those
Speaker 3: you know, those props off of that props object. So
Speaker 3: what props destructure does is it allows you to destructure
Speaker 3: your props from defined props. Okay, so now you're not
Speaker 3: working with props dot blah blah blah, oh throughout the components,
Speaker 3: throughout the script section anyway. Now you can just get
Speaker 3: the actual prop name. Right, So I got this and
Speaker 3: it's it's it's seamless. They're not real reactive refs, so
Speaker 3: you don't have to use that value. They're under the hood.
Speaker 3: It actually compiles back to props dot whatever the prop
Speaker 3: name is. Yeah, it's just super handy. And the other
Speaker 3: benefit is is you can define the defaults in the
Speaker 3: destructure statement. There's no with defaults function that you have
Speaker 3: to do anymore. So, yeah, that's the big ad for
Speaker 3: point five.
Speaker 1: I've wrestled with that for quite a while, uh, in
Speaker 1: a particular app that I do. So that's I got
Speaker 1: to look into this for sure.
Speaker 3: Okay, yeah, definitely do, definitely do.
Speaker 1: Uh see, so I'm looking at your view school article
Speaker 1: on what's coming in three point five. So use template
Speaker 1: ref yep use ID. That's more for server side rendering.
Speaker 1: It looks like it is.
Speaker 3: That's a really cool one though, especially if you're in
Speaker 3: the next world just getting a uniquely generated generated ID.
Speaker 3: But it's that same uniquely generated ID both on the
Speaker 3: client and the server. So there's no more like juggling
Speaker 3: and passing the unique ID that you generate on the
Speaker 3: server down to the client. You just you just call
Speaker 3: it and it's the same everywhere. There's no mismatch hydration,
Speaker 3: mismatch issues, which has just been a pain in the past.
Speaker 1: Right, that's a good segue. So moving into next we
Speaker 1: talked earlier about next and what's going on next, and
Speaker 1: you had mentioned this a few bullet points for those
Speaker 1: in the jobs world who might not know what next is.
Speaker 1: Next is basically next for React. I don't remember which
Speaker 1: camp first, and I know next is alphabetic that alphabetically
Speaker 1: before next, so maybe it came first.
Speaker 3: I think that's the case.
Speaker 1: Yeah, right, I think there has a sort of similar
Speaker 1: tool they came out with. I can't remember what it's called.
Speaker 1: Smelt has spelt kit. So just so you can understand
Speaker 1: the next side of things where View is just primarily
Speaker 1: front of Joba script ne excuse you, the whole server
Speaker 1: and during your stack stee.
Speaker 3: But I think next like had to come out first
Speaker 3: because next is like a play on words on is
Speaker 3: that what it is? Because who would name something nuxt like?
Speaker 1: That's a good question, Yeah, I think it. Yeah, I
Speaker 1: could ask that about View and Drupel and any number
Speaker 1: of other names too, so so interesting.
Speaker 3: Fact. Uh, the name of the framework, View comes from
Speaker 3: the French word for view. Know, that's.
Speaker 1: Fast. Fast.
Speaker 3: View is like the view layer like the u I layer.
Speaker 1: Right, Okay, so that actually has significant.
Speaker 3: You didn't take the same strategy, Evan took the same
Speaker 3: for both view and meat. He just just grabbed the
Speaker 3: French word for yeah.
Speaker 1: The story of I always remember the story of Drupel
Speaker 1: where it came from. And it was actually a typo,
Speaker 1: really and because Dre's Boytart is Belgian and he was
Speaker 1: he meant he was trying to drop hell. It was
Speaker 1: like a French from Belgian word for drop, like a
Speaker 1: drop of water, and it was a misspelling and and
Speaker 1: ended up just sticking with it and it took off
Speaker 1: from there. So sort of funny how some of these
Speaker 1: names come about.
Speaker 3: The best way. Yeah, right, happy accidents.
Speaker 1: Yes, So nuxt, why don't you give us an overview
Speaker 1: of next, what it does and what its capabilities are,
Speaker 1: at least currently.
Speaker 3: Sure, sonuxt is like, the big benefit of Next is
Speaker 3: the server side rending portion. They take a lot of
Speaker 3: I mean, you could server side render with just vanilla view, right,
Speaker 3: but you're having to build a lot of things up
Speaker 3: on your own if you decided to go that out.
Speaker 3: So Next makes it really easy to make server rendered
Speaker 3: you applications. But the really cool thing that's happened with
Speaker 3: nuxts three versus with nuxt two, well number one, they've
Speaker 3: embraced the composition API like wholeheartedly. Okay, so next three.
Speaker 3: Composition API is like the first party way of interacting
Speaker 3: and creating, which I like a lot of view developers
Speaker 3: these days, I think have jumped on the composition API vote.
Speaker 3: I know some haven't, and that's fine, but it's kind
Speaker 3: of the direction a lot of the framework is going.
Speaker 3: But the other really exciting part though about these Nuxt
Speaker 3: steps is that you have the ability to specify where
Speaker 3: and how you're going to render things so grandularly. And
Speaker 3: what I mean by that is you could choose to
Speaker 3: render a certain page only on the client. So think
Speaker 3: about just that one page is rendered just like a
Speaker 3: normal view application. You can skip the knuxt server side
Speaker 3: rendering all together, okay, And that's at the page level.
Speaker 3: You could do the same thing for the server. You
Speaker 3: could say, render this page only on the server, don't
Speaker 3: hydrate it on the client side. I don't want any
Speaker 3: of that JavaScript coming down. And you know this is
Speaker 3: just a content oriented kind of page.
Speaker 1: I don't know, I can about page or something like that, right,
Speaker 1: that's a common.
Speaker 3: Use exactly exactly, So you can do that not just
Speaker 3: at the app level. You used to could do that
Speaker 3: at the app level. Now you can do that at
Speaker 3: the page level, so you can mix and match your
Speaker 3: you know, different rendering modes per page. But then you
Speaker 3: can also even do that at the component level. So
Speaker 3: you could have this, you know, one page is rendered
Speaker 3: universally both on the client and the server, but nested
Speaker 3: down inside that page, you could have a component that's
Speaker 3: only rendered on the server, and then whenever the props
Speaker 3: for that component change, it doesn't run any client side JavaScript,
Speaker 3: It just goes back to the server, fetches it, it
Speaker 3: renders on the server in it replaces that HTML you
Speaker 3: know on the page. So it's a really dynamic way
Speaker 3: of being able to choose exactly when and where you're
Speaker 3: you're rendering your your few components so that that server
Speaker 3: rendered example, is really great for something like rendering markdown. Right.
Speaker 3: Loading a markdown parser into your browser is kind of
Speaker 3: a heavy thing, and a lot of times what we're
Speaker 3: using markdown for is for displaying static content, so we
Speaker 3: don't need that run in the browser. We can save
Speaker 3: so much you know, time in terms of loading by
Speaker 3: just rendering out of the server and sending the loaded thing.
Speaker 3: But then that's just that one component on your page,
Speaker 3: all your other stuff could still be be dynamic, so
Speaker 3: pretty cool.
Speaker 1: So that's sort of the ASTRO approach to things, isn't
Speaker 1: it pretty much where you can everythink server and then
Speaker 1: you can have your I mean, I'm sure you don't
Speaker 1: use the same terminology. They call it islands architecture, where
Speaker 1: you can have your little islands of interactivity in the
Speaker 1: middle of server side content. So that's pretty much the
Speaker 1: at least from that from that high level. But I'm
Speaker 1: sure there's a lot of other more dynamic stuff you
Speaker 1: can do within next, within your.
Speaker 3: Compass, right. Oh yeah, there's there's tons of other stuff
Speaker 3: that can do. But in terms of your comparison ASTRO,
Speaker 3: that's exactly right. That's yeah. ASTRO is the server rendered
Speaker 3: by the fault, right, and then client rendered by opt
Speaker 3: in nuxts is kind of the opposite, m h. It's
Speaker 3: it's universal by the fault and then you can you
Speaker 3: can opt into client only or server only per pageer
Speaker 3: or per component. But yeah, in terms of like other
Speaker 3: things that NUTS has to offer for the view developer,
Speaker 3: just a lot of quality of life things, things like
Speaker 3: auto imports for all the composables in your composables directory,
Speaker 3: things like auto imports for the core view reactive functions,
Speaker 3: you know, things like wrath, computed all that kind of stuff.
Speaker 3: You just they just work. You just use them and
Speaker 3: they work right, which is nice. But if you want
Speaker 3: to still import everything like you have the ability to
Speaker 3: do that. You can turn off the auto imports and
Speaker 3: things like that.
Speaker 1: So so now if you're using NEXT, one of the
Speaker 1: big differences, and I think NEXT is like this or
Speaker 1: some of the other ones, is how your routing is handled.
Speaker 1: Whereas with us with a strictly view front end, you
Speaker 1: have your front end routes that you have to define
Speaker 1: and view router, whereas with NUTS it's all based on
Speaker 1: folder structure. So you'll have a structure and then you
Speaker 1: can define you know, I want my u RL to
Speaker 1: look like this, so that's how you name your folders.
Speaker 1: And then you can pass in dynamic values like ID
Speaker 1: values and you know, so what to render a blog
Speaker 1: post based on its slug or you know, however you
Speaker 1: have identified it, so that's you know, that's a pretty
Speaker 1: common thing. I've seen people. In fact, I've worked on
Speaker 1: an app one time where everything was they were connecting
Speaker 1: to a dot net back end. Okay, but they used
Speaker 1: Next because they liked the page routing instead of just
Speaker 1: straight view on the front end.
Speaker 3: Okay, that's fair and a good opportunity for shameless plug.
Speaker 3: We do have a Laravell course at the school where
Speaker 3: we do that same thing. We use really Ravell for
Speaker 3: the back end as an API, yeah, and we use
Speaker 3: Next on the front end.
Speaker 1: Interesting, okay. Yeah, So my day to day is a
Speaker 1: pretty huge app with Laravell and rest APIs that you
Speaker 1: know was initially built way back in Q two where
Speaker 1: it's all APIs and then the view front end connects
Speaker 1: to the back end, you know, through the defined APIs.
Speaker 1: I myself, you know, people have heard me talk about this.
Speaker 1: I'm a huge fan of Inertia JS if you familiarly
Speaker 1: love Inertia. In fact, I had Jonathan on here a
Speaker 1: couple of times when Inertia was pretty new, and I
Speaker 1: will work with it with Lara Bell Laraval on the
Speaker 1: back end, you on the front end, Inertia in the middle,
Speaker 1: and it's it's awesome.
Speaker 3: Very cool. I've got a colleague just came onto our
Speaker 3: team within the like last eight months maybe, and yeah,
Speaker 3: he was really big in there. Inertia taught me some
Speaker 3: things on it and looks really interesting. I haven't had
Speaker 3: the opportunity myself to use it in product.
Speaker 1: But yeah, it's really like if you're and if you're
Speaker 1: familiar like next is, you know your back end isn't no,
Speaker 1: you're writing in no jess if you're doing any back
Speaker 1: end right. So for someone like me who comes from
Speaker 1: the PHP world and it's familiar with Lara Belle and PHP,
Speaker 1: then that's a godsend being able to use something like
Speaker 1: that that you're already familiar with and you don't have
Speaker 1: to learn, you know, a whole new coding technology. So
Speaker 1: a nurse is awesome, and it's it's so fast, it's
Speaker 1: crazy how fast it is. So I'd be real curious
Speaker 1: to see this course. I don't know if you oh,
Speaker 1: you said it's just Laravell with if you're using so,
Speaker 1: if you're using Laravell for the back end with Next,
Speaker 1: you're still doing the service side rendering because your Laravell
Speaker 1: controllers are returning your your content to your next components
Speaker 1: and it's fully rendered HTML. That it's I mean you're
Speaker 1: using Blade templates for the formatting of HTML or how's
Speaker 1: that happening?
Speaker 2: Uh?
Speaker 3: So it's I'm trying to find the earl here. So
Speaker 3: if you just google the name of the course is
Speaker 3: Laravelle back ends for JS three, uh, and then view school,
Speaker 3: I'm sure you could find it. But the whole approach is, yes,
Speaker 3: we're still server do we service side? Remember in the
Speaker 3: course we might turn SSR off?
Speaker 1: Actually yeah, here it is, okay.
Speaker 3: We do. We turn SSR off, but you would you
Speaker 3: don't necessarily have to. You could do the server side
Speaker 3: rendering a bit. But but basically we used in the course,
Speaker 3: we use next just as the client right and as
Speaker 3: as the JavaScript runs in the client. And the only
Speaker 3: reason we chose to use nexts instead of straight view
Speaker 3: was just because of some of the niceties like the
Speaker 3: auto imports and things.
Speaker 1: Okay, yeah, now I remember from a performance standpoint, one
Speaker 1: of the editions that I'm pretty sure it was NEXT
Speaker 1: three was Nitro, which is basically a rendering engines. So
Speaker 1: can tell us about Nitro.
Speaker 3: So, uh, there's kind of this weird like stacking order
Speaker 3: of what what builds next and the next core team
Speaker 3: actually having a organization now on GitHub called unjs, which
Speaker 3: powers a lot of the inner workings of NUTS. But
Speaker 3: those those packages that are also available for the wider
Speaker 3: community at large to use, and Nitro is one of
Speaker 3: those packages. Right, So Nitro is the kind of the
Speaker 3: server layer there. It renders your view components on the
Speaker 3: server side, of course, and so it's the HTML to
Speaker 3: the browser. But the other really cool thing that Nitro
Speaker 3: enables the nuxt three project to have out of the
Speaker 3: box is API end points. This is something you didn't
Speaker 3: have too. So now you just have a folder in
Speaker 3: your NUTS project called server, and then you have a
Speaker 3: folder inside of that folder called API, and any file
Speaker 3: within that directory automatically becomes an API endpoint. So you've
Speaker 3: really got the whole, like everything you need to build
Speaker 3: a full stack app right there inside of your one
Speaker 3: next project. There's no reason to hook it up to
Speaker 3: an external API anymore. Of course, you still could, I mean,
Speaker 3: there's nothing wrong with that, right We use Layravell in
Speaker 3: the course. But if you don't want to have to
Speaker 3: manage the separate back end, you can actually have your
Speaker 3: entire You can have your rest API and your you know,
Speaker 3: and your actually user facing applications all in the same repo,
Speaker 3: which is is pretty cool.
Speaker 1: So it's sort of a drop in if you have
Speaker 1: APIs written for what any CMS online CMS versus maybe
Speaker 1: something or even something that you have locally such Lavo,
Speaker 1: my XQL or you know, no JS with Mango API
Speaker 1: defined or something like that, then you can drop it
Speaker 1: in and use it with with next.
Speaker 3: Yeah, I wouldn't necessarily say you could drop it in.
Speaker 3: I mean it is. They do have their own syntax
Speaker 3: right now. Okay for for the API in points. But
Speaker 3: if you have the data in a database somewhere, you know,
Speaker 3: you can just start interacting with that database directly via
Speaker 3: these these API and points and then sending the you know,
Speaker 3: the data to your your front end, right.
Speaker 1: And so is it sending everything as props? Then? Is
Speaker 1: it's how? It's how it's how does it send it
Speaker 1: to the front end.
Speaker 3: So on your on your view pages. So you talked
Speaker 3: about that page file based route in just a moment ago, right,
Speaker 3: So uh, in your view components, you call a composable,
Speaker 3: a built incomposable called use fetch and it makes a
Speaker 3: fetch request and you just pass it the route for
Speaker 3: that API end point. Right, So you do slash api,
Speaker 3: slash users or slash posts or whatever. So that's how
Speaker 3: you connect your view pages to those those API endpoints,
Speaker 3: and of course on the server side. On the server side,
Speaker 3: when you make that request, it's actually going to skip
Speaker 3: the network layer altogether, and it's just going to go
Speaker 3: call the function that that API endpoint is is made
Speaker 3: up of. But then on the client side, when you're
Speaker 3: navigating you know, first page load, it's all server side
Speaker 3: rendered and it hydrates. But then as you navigate the
Speaker 3: new pages, it's gonna make that request asynchronous lyad right,
Speaker 3: So uh, it's it's it's pretty nice. Like it handles
Speaker 3: things like you know, serializing your Jason for you, so
Speaker 3: like you can just return an object from the API
Speaker 3: in point. You don't have to serialize it first or
Speaker 3: tell it what kind of data it is or something
Speaker 3: like that. You just you return an object. It assumes, okay,
Speaker 3: this is this is Jason and things like that. You
Speaker 3: also have type safe autocompletions for your for your API
Speaker 3: end point route. So if I'm calling U s fetch
Speaker 3: on my front end on my page, as soon as
Speaker 3: I start typing in the r L, I get a
Speaker 3: list of of drop down autocomplete says what endpoints are available, right,
Speaker 3: so I can just pick, oh I want API slash
Speaker 3: users or I want API slash posts and because it
Speaker 3: all exists in the same project, that makes that possible, right.
Speaker 1: So yeah, so okay, so you mentioned that it's been
Speaker 1: extracted into its own, separate sort of rendering engine. Is
Speaker 1: it still geared specifically for view or is it something
Speaker 1: that can be used with other front ends? You know?
Speaker 1: I think of for instance, VAT. When VS first came out,
Speaker 1: the original literation was view only, and then the next
Speaker 1: version he said, okay, you can plug and play with anything,
Speaker 1: and it's just gone nuts with how many people replace
Speaker 1: webpack with with VT and so on. So is unjus
Speaker 1: is this the same idea or is it still strictly
Speaker 1: for view?
Speaker 3: Yeah, it is the same idea. Everything in the UNJS
Speaker 3: organization is completely framework agnostic, and indeed other frameworks have
Speaker 3: picked up have picked up packages and have built off
Speaker 3: them to make their own own thing. I can't remember.
Speaker 3: I can't remember what it is, but there was some
Speaker 3: other you know how the JavaScript world is frameworks every week,
Speaker 3: But there's there's some new framework. I read about recently
Speaker 3: that they they built their server layer on top of Nitro.
Speaker 3: But yeah, that's that's the approach.
Speaker 1: Hmm. Yeah, I've seen that before. I did some work
Speaker 1: with another company that had a specific JavaScript form render
Speaker 1: everything was rendering forms, and they extracted it, you know,
Speaker 1: and made it open source. They had a story where
Speaker 1: another company used it and made millions of dollars work,
Speaker 1: but they wouldn't even mention the company name when we
Speaker 1: talked to them. But uh, yeah, that's cool when you
Speaker 1: can extract that use it for other things as well. Yeah,
Speaker 1: any other next, next things, new features, you know, anything,
Speaker 1: what's coming down the pike with Next three.
Speaker 3: I know Next four is coming fairly soon. That's I'm
Speaker 3: not totally sure that the biggest thing in Next four
Speaker 3: is there's going to be a change to the project structure.
Speaker 3: Like a lot of the things that we're in your
Speaker 3: root directory for next three will now be nested under
Speaker 3: an app directory an app directory for next four. And
Speaker 3: I think there's some like typescript benefits to that, like
Speaker 3: why you're watching certain files locally or something while you're developing.
Speaker 3: Now it can it can focus on just that one
Speaker 3: app fold or something. I don't remember exactly what it is,
Speaker 3: but it's supposed to make your development process just a
Speaker 3: little bit, you know, faster, your your depth serve a
Speaker 3: little faster or something like that.
Speaker 1: Yeah, so I'm curious. So they're going to do a
Speaker 1: next four but still based on View three? Is that?
Speaker 3: Yeah?
Speaker 1: Right? Because it doesn't sound everything I'm you know, reading,
Speaker 1: I was just reading something by Linusborg, uh that you know,
Speaker 1: View two two. The three was such a huge you know,
Speaker 1: gutting and rewriting of everything and lots of backwards breaking stuff.
Speaker 1: Although they did do so. I think it's still sported
Speaker 1: the option d API, but it was still so huge.
Speaker 1: It sounds like VI four is going to be not
Speaker 1: quite as aggressive, shall we say, or changing going forward.
Speaker 3: Which is a good thing. Yeah. Yeah, And and I
Speaker 3: think the view like where View is at in its
Speaker 3: life It's it's stable, and it's well loved, it's it's
Speaker 3: easy to use, Like I don't think at this point
Speaker 3: in its lifespan you need this this major change like
Speaker 3: we had from two to three, right right, which is
Speaker 3: great news for developers. It's less things we have to
Speaker 3: do to migrate.
Speaker 1: And then are probably hopefully you know, sort of encourage
Speaker 1: people to upgrade from View two to V three, which
Speaker 1: is not a small undertaking undertaking, especially when you deal
Speaker 1: with some very large you know, enterprise type applications.
Speaker 3: And and everything, depending on the libraries you're using and things.
Speaker 1: Oh yeah, absolutely, I do know. And I've mentioned this before.
Speaker 1: I think it was two point seven of you had
Speaker 1: composition API stuff embedded in it, and the idea being
Speaker 1: that you could still be on YouTube but slow sort
Speaker 1: of migrate to V three and then you know, throw
Speaker 1: the switch in and migrate over to V three from there.
Speaker 3: Yep, yep, it's I mean, they definitely made some good
Speaker 3: tooling to help help you make that migration. But like
Speaker 3: you said, the enterprise level, you know size applications, it's yeah,
Speaker 3: it's it's still work and quite a bit of it.
Speaker 1: Oh yeah. We have like upwards of probably five six
Speaker 1: hundred different components in our View two app alone. That's
Speaker 1: been around, you know, for probably ten eleven years. So
Speaker 1: it wouldn't be a small undertaking, especially when you start
Speaker 1: incorporating you know, typescript, because I tried to mess with
Speaker 1: typescript in View two a couple of times and it
Speaker 1: was Yeah, it was not a good experience. I mean
Speaker 1: it's basically sort of bolted on instead of you know,
Speaker 1: built in, right, So it definitely made things a lot
Speaker 1: more difficult, but you know that pretty much any thing
Speaker 1: large is going to be incorporating tax script anymore.
Speaker 3: Yep.
Speaker 1: Cool. Anything else you next related that we didn't cover
Speaker 1: that you're you're dealing with a view school or covering
Speaker 1: mm hmm, well.
Speaker 3: I think we just about covered it all, Steve. I
Speaker 3: guess I do want to throw in one shameless plug
Speaker 3: for our VGs masterclass. Of course, we did release that.
Speaker 3: It's a progressively released course, so we started releasing it
Speaker 3: back in March of this year, and we're still releasing
Speaker 3: lessons where you build a real world application, specifically a
Speaker 3: project management app, something like Asana or a Monday or
Speaker 3: something like that. So if you are you have the
Speaker 3: basics of you down then and you want to kind
Speaker 3: of take it to the next level. Uh, this is
Speaker 3: a really great course for you.
Speaker 1: All right? Cool? Yeah, I've got the you are l
Speaker 1: up here on the screen for those who are watching
Speaker 1: the view JA three masterclass at Viewschool dot Io. Alrighty uh,
Speaker 1: before I forget, if people want to follow you and
Speaker 1: give you money and read all your view wisdom, where's
Speaker 1: the best places to do that.
Speaker 3: I'll have to go set up the donation app right now.
Speaker 3: So that sounds like a great idea. Now, you could
Speaker 3: follow me on Twitter. I'm Daniel Kelly Underscore Io. That's
Speaker 3: where I'm most active, if you can even call me active.
Speaker 3: I'm not a huge social media guy, but you can
Speaker 3: follow me there. View School is view school io on
Speaker 3: Twitter and just you know, just google Daniel Kelly LinkedIn
Speaker 3: or view School LinkedIn you'll be able to find us
Speaker 3: there as well.
Speaker 1: All righty, So with that, we will move on to
Speaker 1: Picks picks for part of the show, where we can
Speaker 1: talk about whatever we want doesn't necessarily have to be
Speaker 1: tech related obviously within recently. AJ, We'll let you go first.
Speaker 1: What do you got for us for picks this week?
Speaker 2: Oil Boy? Have I got a good one for you?
Speaker 2: I don't think I'm gonna take this back, because you know,
Speaker 2: sometimes I make recommendations and then a month later I'm like, actually,
Speaker 2: that was a bad idea. Okay. Browsers finally, as of
Speaker 2: March twenty twenty three, have support for ekmascript modules ubiquitous support,
Speaker 2: So whether you're on iPhone or Android, or Chrome or
Speaker 2: Edge or Safari or Firefox. As of March twenty twenty three,
Speaker 2: all browsers finally support ekmascript modules. That was about eighteen
Speaker 2: months ago, and that's my threshold for when I say, okay,
Speaker 2: it's safe to use a browser feature, because you know,
Speaker 2: a lot of people they haven't had a power outage
Speaker 2: in the last eighteen months, and so if they haven't
Speaker 2: had a power outage, they haven't like their browser hasn't
Speaker 2: been updated yet because they're you know, their computer's still going.
Speaker 2: Or maybe if they're on Windows where you know it
Speaker 2: like just shuts down the computer no matter what you're doing,
Speaker 2: like you're in the middle of typing a document, it's
Speaker 2: like shutting down to update. So I guess like within
Speaker 2: eighteen months, either people have had a power outage or
Speaker 2: their computer has like crashed from pending updates. So with
Speaker 2: that on the browser side, we're good to go. We
Speaker 2: can use ekmascript modules. We don't need transpilers. It can work.
Speaker 2: As of March twenty twenty four, there was a pr
Speaker 2: for uh ekmascript support in Node that is now available
Speaker 2: as an experimental feature in Node v twenty two. So
Speaker 2: I believe that it is now safe to publish ECMAScript
Speaker 2: modules without any transpilers. And so you might say, oh,
Speaker 2: node notes had notes had support for it forever. No,
Speaker 2: it hasn't. Node has only supported note has had the
Speaker 2: red blue function problem, the colored function problem, where you
Speaker 2: can either use ESM or you can use common JS,
Speaker 2: but you can't use both. In almost every module in
Speaker 2: the entire ecosystem uses common JS. So the moment that
Speaker 2: you introduce an import an ESM dependency, now you break
Speaker 2: everything or you have to transpile. But the new feature
Speaker 2: flag is that as long as you don't use a
Speaker 2: top level of eight. So if you just have an
Speaker 2: a knit function or a main function, if there's anything
Speaker 2: that you need to do as part of the initialization
Speaker 2: of your module, if you're willing to just put that
Speaker 2: in a knit function that you export or a main
Speaker 2: function that you export, or you know, as long as
Speaker 2: you couch that or put it in a caching function
Speaker 2: where the first time whatever function needs that thing, you
Speaker 2: know it runs as long as you put the top
Speaker 2: level a weight inside of an export. So basically, as
Speaker 2: long as you don't have a true top level A weight,
Speaker 2: you can now require an ESM module from a common
Speaker 2: JS module, which means that we no longer have the
Speaker 2: red blue function problem. That modules in Node are just
Speaker 2: modules except for that one case if they actually have
Speaker 2: in the body of the sm a weight whatever, and
Speaker 2: I think that I hope, I hope that we can
Speaker 2: all agree that it's a sacrifice worth making to move
Speaker 2: that a weight into a function that's exported as the
Speaker 2: innit function or whatever. So that so that you can
Speaker 2: publish a module without transpiling, and it'd be available every now,
Speaker 2: of course, since most people are on I would say
Speaker 2: most people, since most most popular influencers are now on
Speaker 2: the typescript bus. You know, you're not getting away from
Speaker 2: the transpiling problem, but you can. That's a topic for
Speaker 2: another time. You can have I use the type shirt
Speaker 2: checker every day. All of my code is typed. I
Speaker 2: even am using cql C with node such that I
Speaker 2: had a left join in a sequel statement and sq
Speaker 2: c allows you to write the raw sequel and then
Speaker 2: generate the code. So rather than writing the code that
Speaker 2: generates the sequel, you write the sequel that generates the
Speaker 2: code parameterized all that. It's wonderful. I love it. I
Speaker 2: had a left join in my SQL code and I
Speaker 2: got a type error on one of the things I
Speaker 2: was iterating over. It said, you know, error, this can
Speaker 2: be null and that was the moment when I felt
Speaker 2: we have arrived. Technology is maybe good again, Like maybe
Speaker 2: we're on the right track. If I can write sequel
Speaker 2: and get a type error from a left joint, maybe
Speaker 2: maybe there is a bright future somewhere on the horizon.
Speaker 1: So I was wondering when I was able to sleep
Speaker 1: better at night lately. That answers my question.
Speaker 2: So that's that's my that's my main pick is just that,
Speaker 2: And I I am you know, I don't know how
Speaker 2: many experimental features have made it all the way to
Speaker 2: the point where they have a flag and are properly
Speaker 2: documented in everything, and then don't make it in. But
Speaker 2: this seems like a no brainer. So I'm I'm willing
Speaker 2: to put my my eggs in this basket and say
Speaker 2: it's time to use ESM imports. But for please, please,
Speaker 2: for the love of all that is holy and and heavenly,
Speaker 2: and say in this world, just use one default export.
Speaker 2: Don't have a billion trillion exports. Please. But that said,
Speaker 2: this is something I'm excited about. Uh. There have been
Speaker 2: headaches around this for a long time because of the bundlers,
Speaker 2: not because of the browser. Because of the bundlers. It's
Speaker 2: been a pain in the butt to get isomorphic code
Speaker 2: working in both note in the browser. The browser's super
Speaker 2: easy to do, and note it's super easy to do.
Speaker 2: You don't need to require SHIM or any of that.
Speaker 2: You just need a simple ore. But because of the
Speaker 2: way that the bundlers do the window detection versus the
Speaker 2: global dis detection versus, there's all this crap that you
Speaker 2: like boilerplate. There's like six lines of boilerplate that you
Speaker 2: have to have in order to get a common JS
Speaker 2: module that would otherwise work. Find a note in the
Speaker 2: browser without any problem, without hardly like with one line
Speaker 2: literally one line of quote unquote boilerplate for the bundlers.
Speaker 2: Yet it's it's atrocious because they all do it wrong.
Speaker 2: They don't follow this BAC. They don't anyway. But yeah,
Speaker 2: so I'm I believe. I believe from today onward, I
Speaker 2: will be writing es M import and export. And I
Speaker 2: know that that went way over there are alloted two minutes. Oops.
Speaker 1: Oops. So another we can blame Flow at Progressive for
Speaker 1: all the problems for those who don't understand. In the America,
Speaker 1: we have these insurance commercials down named Flow always talking
Speaker 1: about bundling insurance.
Speaker 3: So they're everywhere.
Speaker 1: That's what comes to my mind. Unfortunately, was that it? AJ.
Speaker 2: I'm hoping you're gonna field the best dad joke ever,
Speaker 2: the best tech the best tech dad joke ever. Yeah, okay,
Speaker 2: all right, are you gonna do it or do I
Speaker 2: need to do it for you?
Speaker 1: Oh yeah? Oh yeah, So let's talk about that. So,
Speaker 1: for those who follow me on Twitter, AJ made an
Speaker 1: attempt at a dad joke that apparently went over my
Speaker 1: head and so I just finally got it explained to
Speaker 1: me this morning before we came on. So you want
Speaker 1: to explain it, AJ, And for those who are maybe
Speaker 1: those who are less dense than I will get it.
Speaker 2: I think it just is your experience, not that's this.
Speaker 2: But oh so Steve was talking to me and he said,
Speaker 2: what do you think about SQL migrators AJ? And I said, well,
Speaker 2: you know, they have their ups and downs.
Speaker 1: Wait sorry, sorry, sorry, I was pulling up a tweet
Speaker 1: and getting because yeah, I didn't get the migration tools
Speaker 1: I've used, didn't don't use the updown, up and down terminology,
Speaker 1: and and so I missed it and I felt sorry.
Speaker 1: It is it a for effort, though I appreciate the
Speaker 1: thought going to the dad joke. Whenever you see that,
Speaker 1: that's that tells me that you're learning.
Speaker 2: Speaking to my heart.
Speaker 1: Speaking of dad jokes of the week, let's see. This
Speaker 1: one's a little long, but hopefully you'll get the It's
Speaker 1: maybe a little more visual, but that's what I got
Speaker 1: for this week. So imagine this thing was Monday, Greg, Tuesday, Ian, Wednesday, Greg, Thursday, Ian, Friday, Greg, Saturday, Ian,
Speaker 1: Sunday Greg. That is known as the Gregorian calendar. Right.
Speaker 1: I was talking to my friend one day not too
Speaker 1: long ago, and I said, you know, I used to
Speaker 1: be a heavy drinker and he said, oh, you stopped drinking.
Speaker 1: He said, no, I just lost weight.
Speaker 3: I saw that one on Twitter the other day.
Speaker 1: Yeah, I wrote that Originally I really like I write
Speaker 1: all my dad jokes and then finally, did you know?
Speaker 1: It's funny when you die, people cry and they're upset
Speaker 1: and they beg for you to come back, but when
Speaker 1: you do, they freak out. So those are the dad
Speaker 1: jokes of the week. All right, Daniel, your turn. What
Speaker 1: do you got for us? Uh?
Speaker 3: So picks? Uh, I'm gonna go with a book pick.
Speaker 3: I have been listening to a book called The fairy
Speaker 3: Tale because he actually reads books anymore.
Speaker 2: Uh.
Speaker 3: Listen to it, uh through Spotify and it's by Stephen King.
Speaker 3: Definitely recommend checking that out if you're you're into Stephen King.
Speaker 3: Very very well written book and it hasn't gotten to
Speaker 3: the creepy part yet, but like there's a little hints
Speaker 3: of it in there and it's very intriguing. So definitely
Speaker 3: recommend that one.
Speaker 1: Yeah, you know, Stephen King, you gotta expect some level
Speaker 1: of creepiness.
Speaker 3: Right, absolutely, absolutely, as far as I'm gonna do. I'm
Speaker 3: gonna throw a music pick in here as well, because
Speaker 3: I've had an earworm for the past week. I'm a
Speaker 3: nineties kid. Does anybody remember Yellow Card? Does that band
Speaker 3: named ls?
Speaker 1: Yeah?
Speaker 3: Us? Yes, all right?
Speaker 2: Is that is that the her hair is everywhere? Or
Speaker 2: is that?
Speaker 3: No? No, no, her hair is not everywhere? Believe? No, no, no.
Speaker 3: What was the name of it? The very popular one? Man?
Speaker 3: I can't even remember the most potful one they have.
Speaker 3: I think it was called Believe, but I'm not singing
Speaker 3: it for you.
Speaker 1: Uh.
Speaker 3: Yeah, that's been my earworm for the past week. Very
Speaker 3: you know, heavy guitars. They have violin in there, which
Speaker 3: is really interesting.
Speaker 2: You know. I love that I think that that's the best.
Speaker 2: When when Hello Maybe came out, that was one of
Speaker 2: the things that I thought was so great. I love
Speaker 2: orchestral crossover in any music, be it punk or rap
Speaker 2: or anything. I love orchestral crossovers.
Speaker 3: Oh it's it's beautiful because you have h I mean,
Speaker 3: they live. They have a violinist in their band, and
Speaker 3: so she'll do this like solo, violent thing, and then
Speaker 3: the the whole band will kick in and it's really
Speaker 3: cool selling. But I think Believe is the name of
Speaker 3: one of the most popular.
Speaker 1: Songs, Okay, Believe by Yellow Card. I was not familiar
Speaker 1: with that band, but then I wasn't really listening to
Speaker 1: a lot of radio in the indies.
Speaker 3: If you remember a story of the year. They kind
Speaker 3: of remind me of them slightly, just a little less.
Speaker 1: Screamy, less screamy, more musical. That's right, cool, alrighty, Well,
Speaker 1: thank you Daniel for coming on. It's been good to
Speaker 1: have you. It's been good to talk to you on
Speaker 1: JavaScript Ever. We've already talked about where people can give
Speaker 1: you money, So thanks everybody for watching and listening, and
Speaker 1: we will talk to you next time on JavaScript Ever.