Austin Gil is a Senior Developer Advocate. He joins the show to talk about "Web Fundamentals". He begins by explaining its purpose, and the importance of knowing web fundamentals as a developer or programmer. 

 

Hey folks, and welcome back to another episode of JavaScript Jabber. This week on our panel, we have A.J. O'Neill.

 

Yo, yo, yo, coming at you live from the shed.

 

Steve Edwards.

 

How you doing coming from somewhat sunny Portland? It's finally warming up around here.

 

Right? Dan Shapiro?

 

Back home in warm and sunny Tel Aviv.

 

I'm Charles Max Wood. I'm coming at you from a broken standing desk. It doesn't go up anymore. We have a special guest this week and that is Austin Gill. Austin, how's it going?

 

Hey, doing well also here in Portland with Chuck or with Steve and yeah, the weather is getting really lovely Come

 

Oh,

 

visit.

 

nice.

 

It's great

 

Good deal.

 

Yeah, I need to visit Portland. I have never been.

 

Okay, if you do, let me know I will take you out. I'll show you some fun things that are like off of the all top 10 things to do important thing important list. And yeah, good places to eat lots of fun activities.

 

Yeah, I haven't been to Portland in a long time, but my wife's best friend used to live out there and it was a fun town to visit for sure. Today we're gonna be talking about fundamentals and what's fundamentally wrong with being fundamental about fundamentals and not to get too fundamental or be fundamentalists. I think, okay, that was terrible. Anyway, I'm gonna let Austin kind of talk a little bit about this, because I think there's... kind of some ins and outs to the way that we talk about kind of the basics or the fundamentals. And he, he explained it better than I did before the show is really what it boils down to, so.

 

Well, thanks, Chuck. I don't know if I did, but I will do my best to get into it. Basically, yeah, I kind of proposed this topic because I have spent a long time in, well, what I consider a long time, 10 years, just getting started to some of you, but what I consider like a long time in the web development space. And I think that throughout these years, I have seen a lot of conversations around fundamentals that I think Um, doesn't, doesn't the word itself is just a loaded term that doesn't quite capture, um, it doesn't do it justice justice. So we talk about fundamentals a lot in the conversations on, uh, learning paths on how people should get started in web development

 

Mm-hmm.

 

and where they should begin, whether they do framework first or, uh, fundamentals first, or, and that, that kind of coincides with things like boot camps versus going to school and getting a CS degree. And I think that the problem with this conversation is that it assumes that fundamentals are kind of, you can kind of just learn them and be done with them, or it assumes that everyone has the same learning patterns, or it assumes that everyone's coming from the same context or circumstance. And in reality, there's no right answer to which one you should begin with, or what you should choose for your journey. I think that... We tend to kind of see the things that work for us or discover later on the advice that we wish we would have had earlier on and try and assume that that's going to be what works for someone else. And that's so that's like part

 

Thank

 

of the

 

you.

 

fundamentals and the other sort of loaded term with fundamentals is that it assumes that it's sort of beginner context. And in reality, I think that there's so much nuance. So a little bit of backstory here is is the sort of fundamentals that I've spent a lot of time focusing on is I did a deep dive into how forms work on the web and more recently a deep dive into how to upload files and how to deal with file uploads in an application both from just enabling it on the front end, receiving files on the back end, how to store them for performance and security and cost effectiveness and there's just, you get into these things that we call quote unquote fundamentals, and that makes it seem like it should be easy. And in reality, these are very nuanced topics that, you know, takes a whole career to learn.

 

So in that context, I really need a better definition, I guess, of what you actually mean by fundamentals. Because it seems that you mean by… it seems like what you mean by fundamentals is functionality built into the browser. But

 

Yes.

 

as opposed to functionality that's provided by… I don't know, let's say frameworks that are implemented on top of the browser. But then you also refer to things that we might learn in a university course, which I take to mean things like, I don't know, recursion, data structures, stuff like that, which aren't necessarily related to a particular technology. Uh, I don't know that people who work in, in you know, vanilla JavaScript as it's sometimes called, are more likely to use sophisticated data structures than people, let's say, working in React. Maybe they do, maybe they don't, I don't know. So what exactly are you referring to or thinking about when you're, you know, speaking about fundamentals?

 

Yeah, so this is kind of the problem. You're highlighting the fact that, you know, I mentioned fundamentals is such a loaded term that can mean different things based on

 

Mm-hmm.

 

context. So if we're talking about just computer science fundamentals, then, you know, those are things like sorting algorithms or design patterns or how memory is allocated in the computer and what garbage collection is and things like that, right? And these are often things that Uh, you can go an entire career and never even know or understand and still be extremely successful. Um, but then in different contexts, like you said, in the context of, uh, web development, maybe the fundamentals are what browser specific APIs are available. Um, in HTML, CSS and JavaScript. Uh, and when we're talking about, uh, JavaScript programmers versus like framework authors, I think that there's even fundamentals that a given framework might provide, like building your hello world version of whatever language is hot of the week. That's going to cover some of the fundamentals. So the problem is, I think that there doesn't seem to be an appropriate term for all of these things. And yet they all sort of overlap. And

 

Well,

 

Yeah, I don't know.

 

one thing that I see too is that, you know, over the course of my career, I have picked up different technologies, different ideas. Sometimes we see things evolve, right? And so I go and learn something that is foundational or fundamental to what I am working on today that you could consider fundamental. I'm making air quotes. I call them scary quotes when I make them, but I'm making air quotes around it because, you know, yeah, it is fundamental to all kinds of work, but it hasn't been fundamental to any of the work that I've done yet, right? I haven't paid the price of not knowing it. And so, yeah, it's a fundamental, but it's only a fundamental now because I'm doing something different from what I was doing before, if that makes sense. And so some of these things change, right? The other thing is, is that, and here's another example, and just to highlight this even further, so when I was in high school, I swam competitively. And then I didn't do it for like 20 years, and then I picked up triathlons, right? So yeah, I'm one of those nut jobs that goes and does three sports as one sport. And you know, I go out in the deep water with no life jacket, wetsuit. And I joined a swim team and I had a swim coach at 42 teaching me swim fundamentals because I'd forgotten them because I'd been doing it for so dang long. And so I got in the water and yeah, I stayed afloat and moved down the pool, but she was teaching me fundamentals on how to move faster, how to be more efficient in the water and things like that. And so that's the other thing is that sometimes we get into a practice where... we kind of know the fundamentals. She didn't teach me anything I didn't already know, but she was able to point out where I failed on some of the fundamentals and I brought them back around. And so I think we've got this idea that it's all for beginners and that may not necessarily be the case, but they are things that

 

Exactly.

 

we have to understand as a basis for the things that we're doing if we want to do them well.

 

I do want to make a few distinctions though. One first of all has to do with some fundamentals that you just mentioned Austin. You referred both to search algorithms and to garbage collection in the context, let's say, of JavaScript developers. Now realistically, JavaScript developers are wholly unlikely to ever implement a search algorithm because they'll probably just use the built-in sort in arrays. So knowing sorting algorithms is more about maybe training your mind about how to develop algorithms to solve certain problems and data structures and supporting technologies, not necessarily as direct technologies that you might be using day to day. On the other hand, you mentioned garbage collection. And in that context, even though that's again, quote unquote fundamental technology, and you can get by without knowing, what garbage collection does and how it works, I think that that lack of knowledge actually does to an extent cripple you, that's a bit of an extreme term, but it limits you in your abilities. as a front-end or JavaScript developer. I think it's such a fundamental concept that not knowing it is a significant lack in your understanding of how this system works. And another point that I wanted to make is that there are fundamentals beneath fundamentals, and

 

Thanks for

 

they

 

watching!

 

don't get any simpler. Usually they get ever more complicated. For example, we are all running on top of the browser. The browser is implemented by a lot of heavy duty C++ code. Do you need to know C++ in order to properly use the browser? Well, obviously you don't, but somebody does. So,

 

I feel so inadequate.

 

you know.

 

Yeah. So

 

Well...

 

yeah, I mean, it's kind of this whole conversation that fuels, well, to make a correction, Dan, I think that my comment about the fundamentals in memory allocation and garbage collection and sorting algorithms, that was in the context of a computer, like someone that goes and gets a computer science degree versus someone that goes to a bootcamp, because those topics generally are probably not covered. But then if you shift concept, context to... JavaScript, yeah, I don't, I have never, have never had to worry about garbage collection because JavaScript implements that for me. Like I don't have to manual, well, sorry, I have to know about it, but I don't have to manually implement garbage collection

 

Oh, you

 

like

 

don't

 

in

 

need

 

other

 

to,

 

languages.

 

obviously, very few people, by the way, implementing garbage collection properly and efficiently is one of the harder things to do. These are like the top developers who are working on garbage collection in various platforms like the JVM or JavaScript engines. It's really difficult. But understanding some basic concept of garbage collection, like the distinction between memory that's no longer needed versus memory that can no longer be used is fundamental in my opinion, again, going back to that term, and not understanding that will mean that you have a strong potential of having leaks, memory leaks in your software. without even understanding what memory leaks mean.

 

Yeah,

 

AJ looked

 

like

 

like

 

so.

 

he wanted to chime in, so I'm gonna give

 

Yeah,

 

him a shot real quick.

 

sure.

 

No, you

 

Ha

 

didn't?

 

ha!

 

Okay, nevermind.

 

Okay, so the interesting thing, you know, like it's fine to have these sort of nebulous conversations and, you know, flex our brain muscles about hypotheticals or theoreticals. But I think sort of bringing this back to a JavaScript conversation is Dan, to your point about understanding memory allocation and how that could influence ultimately performance on the front end. This comes into things like knowing what would be like a JavaScript fundamental of how equality comparisons work in JavaScript, where you have objects versus primitives, and understanding how comparing objects might cause bloating of memory, or being able to describe the difference between a map or when to use a map versus a weak map, or something like that. And these things that, especially... Dan to your sake or your area of expertise and performance, like those are the things that could potentially lead to memory leaks, but they're so nuanced and maybe nine times out of 10, it's not going to bite you in the butt, whether you use a map versus a weak map, but then that one time understanding what each one does, how they release the values that they're holding onto in memory and how that has to sit in with your application is like fundamental and could be the critical piece to making the application work.

 

From my

 

Well,

 

experience

 

and I was gonna say,

 

on that, oh, go

 

I've

 

for it, Chuck,

 

never

 

sorry.

 

had to learn that stuff because I've never run into a problem that was that important to me that this actually solved, right?

 

So specifically to that problem, if you're developing a regular, let's call it again, air quotes, website or web page that's loaded, you know, stays in the browser for some seconds to a couple of minutes, then you probably don't need to worry about memory because there's very little likelihood that you'll get anywhere close to running out of it. But if you're implementing a long-lived uh... uh... web page like this uh... not just a single page application but one that you know hangs around for a lengthy period of time i don't know a twitter or or facebook or conversely if you're developing for node and those issues can become really significant really quickly Um...

 

Yeah, where you just restart the server every month.

 

Uh, you know,

 

We used to do that in Rails land, we don't do that anymore, but...

 

yeah,

 

Yeah.

 

but and even then, I mean, I mean, if you're like only have, I don't know, like 50 visitors a day, then then, you know, then whatever. But if you have several thousands or tens of thousands,

 

Mm-hmm.

 

which is not really out there these days, you probably want to be more efficient than that. Let's put it this way. But going back to the fundamentals that you were talking about, my understanding that when you're talking about the fundamentals, what you really mean are the fundamentals of the web, which are the HTML, CSS, JavaScript itself, the language

 

HTTP.

 

and the HTTP and the browser DOM. Would those be the fundamentals that you're primarily referring to?

 

Yes, yes and no. I mean, like those are the primitives, right? And when we talk like fundamentals, this is the challenge with this conversation is it is very broadly encompassing. Like if we're saying just vanilla JavaScript and DOM APIs that are available in the browser, even that covers things that are so uncommonly used that it's hard to say, well, this is a, like you need to know about the web auth and our authentication API or whatever. And like currently that's so infrequently used that Do you call that a fundamental? Does that make it a fundamental just because it's part of the browser API or the DOM? So.

 

The Dom is huge!

 

I think it would be hard to call

 

Yeah,

 

something

 

exactly.

 

a fundamental that came in 20 years late.

 

Well,

 

Yeah.

 

okay, so, you know, is XMLHTTP request, is that a fundamental now? Because it's

 

Oh no,

 

one of...

 

it's dead. Ha ha ha ha.

 

Well,

 

You know?

 

there's, I would say the fundamental is understanding what a header is and understanding what the, basically what the event loop is. Those are the fundamentals. If you understand headers, body, and the event loop, then it doesn't matter whether you use the XML HTTP abstraction or the fetch abstraction. The fundamental would be the thing that when you understand the fundamental, you can understand what trade-offs the abstraction took.

 

Yeah. And this gets really interesting too, because at some point this says, well, you know, if you make the claim that learning the fundamentals or understanding the fundamentals is better, maybe, maybe not whatever. But if you go down that route, then you find a lot of discussion around people preferring, let's say, let's take HTML CSS kind of out of it for the moment. But just JavaScript, you say people, well, people that rally against frameworks. Right. And then say, okay, well, vanilla JS is better. So you should use that. Maybe it is, maybe it isn't in some context, but eventually if you go long enough with a vanilla JavaScript solution, you end up building so many abstraction layers that you build your own framework or your own library. And then you have to recreate something, you know, it's like the generic discount store brand, uh, react.

 

And conversely, no framework, even the large, even the one that are the most holistic, I don't know, an Angular doesn't cover the entire DOM. And intentionally so. I mean, whatever, you know, in React, we have use effect because, you know, we need to access the DOM outside of React every once in a while. And that's the escape hatch. And, you know, it's the escape hatch everybody uses, which means that everybody really needs to be able to access the DOM for one thing or another. So, I really consider the concept of fundamentals as the things that are underneath the common knowledge, as it were. So, and let's say we can kind of agree that if you're coming into the bootcamp route, you're probably learning React because that's like the de facto standard these days for almost for how to build websites. And that's what bootcamps teach. So the fundamentals would really be the technologies underlying React. If it's something that React doesn't even try to do itself. then I don't really know if that would be considered a fundamental. It's just something that you may or may not need to use based on the type of applications that you're building.

 

Sure, I think if I were to describe the fundamentals, it would be the knowledge necessary to explain how fill in the blank works, or to explain what it's doing. So if we're talking about React, right? Or building an application with React, maybe the fundamentals are like, live within the context of React. But if we're talking about how React's reactivity system work, then you have to understand maybe some deeper level fundamentals or primitives. in the JavaScript ecosystem, which talks about design patterns and maybe like PubSub or I actually don't know how the reactivity system works. But having the understanding of what the language has available that's powering it and being able to at least come up with some reasonable explanation of how it can work and understanding Uh, you can't grab, you can't reference the title of the page or like the, uh, the content of an H one in a variable and then change the variable and see the DOM respond. That's not how the DOM works. And that's fundamental knowledge, but somehow react gets us in a, in a place where we can kind of do that with, with bindings, right? Um, so, so yeah, being able to kind of understand what's going on at a deeper level is. but I would call the fundamentals.

 

So,

 

And

 

here's another

 

this

 

interesting

 

is essentially

 

dis...

 

how I got into my career was, I learned Rails, right? And then I learned Ruby afterward when there were places where I had a gap that I had to figure out. Sorry, Dan, what

 

And

 

were

 

it

 

you saying?

 

goes down, it goes down all the way until you

 

Yeah.

 

get to one, you know, it's turtles all the way down.

 

Yeah, but I think again that there is an interesting distinction here. Because when you're looking at the concept of React running on top of the browser, then fundamentals might either be how the browser itself works underneath React, which means, you know, the DOM, which

 

the

 

is...

 

Virtual DOM.

 

No, that's a distinction. So there's the browser itself as it works underneath React, but... you know, technologies that are not specifically tied to React. And then there are the fundamentals of React. So, and that's kind of different, because, you know, if I'm using some other framework, which is not React, if I'm using Svelte, then I don't really need to know about the virtual DOM, because there is no virtual DOM when I'm using Svelte. So then... Virtual DOM is not part of the fundamentals anymore when my stack is svelte. But the browser DOM still is. So even in that context, there are different types of fundamentals is what I'm trying to say.

 

Yes.

 

Hahaha!

 

Yes, I mean, yeah, like that, the point of this whole discussion is, is sort of coming back to that idea is that it's, we're not going to reach the end of this show, like spoiler alert, if you're listening, we're not going to reach the end of this show and have some conclusion or have some definition, right? It's, it's

 

Yeah,

 

a bit of

 

but...

 

a discussion, but I think we should also bring into like It shouldn't be too heady. We can talk about some of the more practical examples of where this shows up.

 

So

 

that's

 

can you give

 

kind of

 

such

 

where

 

a

 

I

 

practical

 

wanted to go.

 

example? Yeah.

 

Because

 

Okay,

 

ultimately,

 

yeah.

 

you know, I'm looking at this. I have people ask, the question I get asked all the time, besides how do you start a freaking podcast, is how do I stay current on all the stuff coming out in JavaScript, right? And so they're looking

 

Mm-hmm.

 

at all the new stuff. But it's a lot of times, you know, some of it's the same question. How do I know what the fundamentals are in my case, right? And then how do I go learn those? so that I can be effective in whatever comes next.

 

So in my experience, a lot of my time lately has been spent playing and learning with some of these different frameworks and transitioning to figure out how it is that they, like, how do you do this in this flavor? And I've gone most recently in the Vue world with Nuxt.js, in the React world with Remix, been playing around with Quick and with Solid. And they're all cool for their own particular reasons. It takes a lot of knowledge and experience to understand what it is that makes it different and why that is significant and to understand how the implementation details are different. I think that that's where you need a solid, not that you need, having a solid understanding of the fundamentals of how the browser works, how JavaScript works, how HTML works, what's available in the DOM. If you're going to be a web developer, having those fundamentals that... the understanding of those fundamentals makes it so much easier to know where the boundaries are between a library or framework and the con or the environment. So like the browser or node or whatever, and then having an understanding of where the boundary exists between the runtime and the language and what each of those different things offer and what their limitations are. So yeah, getting to a practical example, I would say is, I mean, I love talking about forms on the web and uploads and there's good examples for either or. I think with forms, with forms, it's really interesting because we have these, we have these projects. I also played with SvelteKit. So we have these projects like SvelteKit and Remix that are very pro platform, very pro progressive enhancement. which is another topic all on its own that is really fascinating. But the idea is you basically ensure that your application runs at a minimum sort of environment. So in their case, or in our case, talking about the web, that it'll work with just HTML primitives. We have two ways in HTML to make an HTTP request. We have anchor links and we have form tags. But in the context of forms, you can take that Build out with HTML in such a way that it will work and then you can bring in JavaScript if the environment Supports it so it's a browser that has JavaScript enabled that has a fast enough Run or a fast enough connection that I can download the JavaScript and parse it and there's no errors and there's no issues with this with a CDN or the ISP blocking it or an ad blocker or all of these things that all these reasons why JavaScript could fail right you basically ensure that it'll work in the absence of those. And then when JavaScript is available, you have a nicer user experience by submitting the form without a page refresh.

 

Yeah

 

And there's so much, but there's so much in there. There's so many things that you have to do as a JavaScript developer, and therefore you have to know about to maintain feature parity. Because if you break it, it sucks for the user, right?

 

But then don't these frameworks basically just do it for you in a way that you don't need to think about it or how they actually implement it?

 

They do until you want to get off the happy path, right? So if you want your... So we're talking about forms, so we're talking about HTTP requests, right?

 

Mm-hmm.

 

So if you want the response from your HTTP request to behave slightly different on completion, you may not... The API that the framework author has designed may not allow for your needs, in which case... you may have to re-implement your own solution.

 

Well, from my perspective, frameworks exist because most of us are on the happy path most of the time. Frameworks

 

Till

 

kind

 

we're

 

of

 

not.

 

provide until we're not, and that's when the experts come in. But yeah, I mean, you know, frameworks exist because we built mostly the same applications again and again and again, and that kind of defines what the happy path is. And that's what the framework strive to provide. It's again, when you're kind of stretching the limits or approaching the boundaries is when you can run into problems and I totally appreciate that. And unfortunately I often spend some of my own time there. But most developers don't need to, certainly most of the time.

 

Yeah, yeah, certainly most of the time.

 

And when they

 

And that's

 

do

 

kind

 

get

 

of

 

there these days, they can always just ask chat GPT.

 

Sure, sure. And yeah,

 

Wrong

 

I

 

answers

 

mean...

 

only.

 

Hahaha!

 

He

 

And

 

said experts.

 

that is the direction that we're going towards, right? And that's fine. Like if ChatGPT is going to be the next Google and can answer the questions, great. I mean, they're tools that can help us. I think, again, that sort of comes back to, you have to have a basic understanding of the fundamentals to know whether ChatGPT is bullshitting you or not. And AJ just,

 

Exactly.

 

yeah.

 

Yeah.

 

That's that's the thing that chat I think chat GPT is a better resource for experts than it is for beginners in some ways. And that it gives you the vocabulary and the terms you need to search for like I can paste it. I love that I can paste in syntax and get it to tell me what a possible name of that syntax is because you cannot search on syntax. And it can also take a description. So I was looking for the sums, the subset sum problem is what I was looking for. And I described the problem and then it told me this is the subs the subset sum problem. It's a computer science problem of. Kind of sorting slash selecting integers from a pool. But you know, so stuff like that where it's it's really, really great. But then. If you think that it's giving you correct information, that's where, and it's going to do great for homework assignments. It's going to do great for hello worlds. It's going to do great for things of which there's literally thousands upon thousands of examples that are almost identical, but as soon as there's any nuance or creativity, then it just completely blows up and I'm just worried about the noise factor on that one. If people, the noise in the system, creating a feedback loop where people get less, they get more ignorant because they think that they know something that previously they knew they didn't know.

 

Hmm

 

I

 

and

 

would

 

again

 

also

 

go

 

put forward, oh, go ahead.

 

yeah go for it

 

I was just going to say, I would also put forward though that I've had the same problem with like stack overflow and what Google points me at,

 

Oh yeah, for sure.

 

right? Either because it's out of date or because somebody was wrong and a bunch of other people didn't realize they were wrong and thought they sounded smart and up voted the thing.

 

But you've got the source material, so you can see what they

 

Yeah.

 

actually said in context, rather than mixing and matching multiple contexts. And then

 

Yeah.

 

you also have the comments that help you to understand with even greater context. You can see where there was an edit or an error because somebody said, oh, this is wrong. You should change it. And you can look to see, oh, yeah, it does have that included in what?

 

Interestingly, I think that chat GPT is just kind of raising the bar or changing what we consider to be fundamental or not, going back to our discussion. One of the purposes of successful frameworks or programming languages or systems is to get away from boilerplate. And

 

Mm-hmm.

 

chat GPT kind of tries to get you away from boilerplate by kind of providing you the boilerplate implementations, you know, out of the box. But again, going back to the concept of fundamentals, it's interesting for me, and you mentioned a couple of frameworks, to see how what we mean by fundamentals fluctuates over time. Because if you're talking about the examples that you gave, like forms, forms have been here forever. and will remain a part of the web forever, like a defining aspect of what the web is. But you mentioned a couple of the new frameworks that are coming out, like quick and solid. And all of a sudden, you have a new fundamental, which we, by the way, discussed a few episodes back with Ryan Corneato, which is signals. Like a year ago, nobody was talking about signals. And now, they're a fundamental concept. that's underlying QUIC and underlying SOLID, and now also starting to underline Angular. So it's interesting to see this kind of topic, which nobody was thinking about, becoming a fundamental topic. And I would argue that you cannot properly use SOLID or QUIC. I don't know what the situation will be with Angular, but you cannot properly use. solid or quick without understanding signals.

 

Right, I remember when we had this fancy new feature in a library called Promises, right? And now it's just, I mean, it's just the cost of doing business on the web these days.

 

Yeah, it's a funny

 

Or something

 

one because

 

like it.

 

I have to say something about promises because people really were starting to understand promises and then a sink of weight came along and now it seems like a lot of people can get by with promises without actually understanding promises.

 

until

 

I resemble

 

they...

 

that comment.

 

until they... until they don't. I mean,

 

Right, till they hit

 

I've

 

the

 

said

 

edge

 

it a

 

case,

 

hundred times.

 

which is the same thing we've been saying with everything else.

 

And that's where you need to understand what's going on.

 

But

 

Sorry, cut

 

if

 

you

 

you

 

off,

 

understand,

 

EG.

 

you have to understand callbacks because the callback is the fundamental, the event, the event,

 

Well, the event

 

the event

 

loop

 

loop

 

is.

 

is the fundamental and then the callback. And then a promise is simply an object that has an array of callbacks that should fire on success and a separate array of callbacks that should fire on error. And on top of that is a sync await and

 

Yeah, but here's the thing JJ, because if you

 

you can

 

use

 

get

 

a

 

away

 

sync

 

with.

 

await, you don't

 

Yeah.

 

see the callbacks.

 

And that's it's I feel like async away is an advanced feature for for experts only. Because if you understand all that's going on underneath,

 

Except that

 

then

 

it's

 

you

 

used

 

can

 

by everybody.

 

use them.

 

But

 

What?

 

Yeah,

 

if

 

exactly.

 

you don't understand it, if you don't understand it, then you look at all the blog posts that are written and you copy and paste it. And if you're not an expert to know that this is expert only territory,

 

and

 

you're

 

you can

 

in the

 

get

 

forest

 

away

 

without

 

with

 

a

 

it

 

map.

 

90%

 

Yeah,

 

Yeah.

 

of

 

like.

 

the time.

 

I get that, but what I'm saying is there's so much nuance to async await that if you say, oh, promises are complicated, I can't understand this, so then you just throw async await around one, you're using it incorrectly, you're using it as an anti-pattern, and then when something goes wrong, you are completely clueless as to what and why. I feel like async await. I remember the very first time that I was using jQuery and having a race condition. And when I had that aha moment of, Oh, I don't know if I had the words for it yet, but I got the, this is what the event loop is. This is what function scope is. I remember having that aha moment working on a project years ago. And I feel like async await takes us back to the set timeout days in many ways where It's like, can't figure out what it's doing. Just set time out to make it work. And that's kind of, that's kind of how

 

they've done

 

async

 

that.

 

awaits seems to be used. It's like, I can't figure it out. Maybe if I throw the word async in front of it, maybe if I throw the word await in front of it, maybe if I get rid of the word await.

 

I always recall the situation where I worked with a guy who was a fairly senior C++ developer and he was transitioning to become a front-end developer. So he was literally learning JavaScript by himself as a seasoned developer. And then one day he comes to me and says, I need to do an Ajax request. I don't recall if Fetch was already around or he was using XMLHTTP request. But basically he said, I need to do this request. and I need to block until it finishes. How do I block? And I remember his astounded look when I said, you don't. And these days he probably throw and I wait on it and move along happily on his way.

 

Yeah, I mean, it just comes down to like, if you don't know what you don't know, right. And so people that are using async away are going to, and honestly, that's fine. Like, I think that if you like, I think that, I think that stumbling across these things and getting bit by them is the path to understanding the fundamental below, because that's when that's when you're forced to. And there's a lot to be said about people that just build and build and build and ship and don't understand. everything that go I mean, to some layer, like at some level of abstraction, no one can explain everything that's going on.

 

Oh for

 

And

 

sure.

 

that's fine. You know, I mean, Dan Abramov has a really nice post that he's like, it was something about the things that he doesn't know. And everyone just assumes that he's an expert at everything, because he's an expert at, you know, his one thing.

 

He's not, now I'm really feeling inadequate.

 

Yeah, but related to that, for me, that's one of the main advantages of either having a mentor, an experienced

 

Yes.

 

mentor, or working in an organization that prioritizes learning and advancement. Because on your own, you can learn the fundamentals, but there's a good probability that you won't know what the fundamentals are and certainly which fundamentals you should learn.

 

Mm-hmm.

 

And working with somebody who's experienced, they will be able to not only, you know, either just teach you the fundamentals or at the very least direct you towards the fundamentals and understanding what are those fundamentals that you need to know.

 

Yeah, I have to say that I think that's one of the keys to this is when I was figuring out fundamentals to Ruby and then later when I was figuring out fundamentals to JavaScript, you know, and fundamentals to anything else that I'm using, whether it's an open source tool or something like that, a lot of times I've had that experienced voice next to me, right? And so it wasn't so much that, hey, I'm going to mess this up. It was, hey, this is why it's not going to do what you expect it to, right? here's some other piece of knowledge that's going to unlock what this actually is. And so at the end of the day, then I can go, going back to our previous example, I can go async await something without having a deep knowledge of promises or whatever that underlies it, but I know enough about it to know that, hey, look, if I do any of these things, it's not gonna do what I think it's gonna do.

 

By the way, in this context, I need to give props to us that if you want to know about the fundamentals of JavaScript, we had a whole bunch of episodes about it. You know, the things,

 

Yeah.

 

the JavaScript things that you must know and the JavaScript things that you should know. And we basically kind of listed out those things that you should or maybe should need to know. So both what the fundamentals are and what they aren't. Similarly, we had a few episodes on the fundamentals of React, not the implement, not the specific API details because you can't really do that in a podcast, but the basic concept that are underlying React and kind of get you and help you to get what React is about, as it were. So again, the fundamental concepts of what is the VDOM? Why does it even exist? Why is it needed? I think that without having some understanding of the... You can work and react without knowing about the Bid'om at all. I mean, can you? Certainly you can. You can, you know, pay the bills, have a good job, steady income, whatever. But you're limiting your abilities to, you know, make the best use of your primary tool that's in your toolkit. And any... You know, it does limit you not knowing, for example, what the Vidom is. In my opinion, at least.

 

Yeah, and also in debugging, I know that the VDOM and React's synthetic event system is... Good to understand how it works that it's there.

 

Good enough to understand to know that we should really hope that they finally get rid of it.

 

Yeah,

 

Ha ha ha.

 

basically the potholes. Um, yeah, that, that, that kind of brings us back to the fundamentals. Like he just say, well, I don't know. I've been playing around with some interesting ideas of, uh, going way back to the, like just vanilla JS stuff. Um, and using HTML as a declarative language to, uh, to, to set the rules for how the HTTP. Uh, requests should work. So HTML defines the action and the method on the form and the ENG type to set the content type and then the inputs define their validation logic and you just use JavaScript to like you can use the same JavaScript function to then submit every single form. You don't need you know, I don't know how many how many projects I've seen where every form on the page has its own custom JavaScript event handler because it has to submit to a unique API endpoint and has to Jason, you know, Jason stringify all of the inputs that all have their own state management binding so that you can grab it from memory and it's just like the browser has all of that built in already and you don't need, you don't need robust HTTP libraries or validation libraries, unless maybe that is a major part of your application.

 

One thing that definitely used to annoy me, and we see a bit less of it these days, especially thanks to progressive enhancement, is that when a lot of the frameworks came out, like one of the first examples they would give would be form validation and stuff like that. And, you know, but basically that's what HTML5, which is now just HTML, was created for. I mean, all this functionality is just. built into the browser, you don't need a framework if all you need is like the basic ability to do some form validation and submit the form. The browser just does it for you. And in many ways, frameworks just get in the way. And I'm happy to see that, you know, kind of thanks to Remix and now to SvelteKit, that the frameworks are kind of embracing. the way that the browser does for.

 

So this also gets into an interesting topic that we were discussing before we started recording. And that is that remix, well, I'm not sure about remix, but a lot of these libraries are enabling RPC, which is a way to basically define a function within, like, co-locate your back-end function. with your front end logic. And this becomes interesting in things like, I think React server components is going to

 

Mm-hmm.

 

be, or is RPC, Solid.js supports RPC, Quick does RPC with their, you know, these

 

Server

 

functions

 

dollar.

 

that end with a dollar sign

 

Yeah.

 

or whatever. Yeah, they're server side, they're server side functions. Remix does their own version of declaring a function that's going to be a server function. They do that with named exports. Svelte kit does their own version with a separate file. And it's interesting because on one hand, it's great that it allows developers to co-locate their display logic with their backend logic. But again, if you don't understand the fundamentals, you don't understand that some, you may not understand that in this one same file, you have front-end code and back-end code. And there are some things that you can only do on the front-end because that's the only place that the window object is available. And there's some things you can only do on the back-end because that's the only place that your database credentials should be available. And if you don't really understand that, you could confuse the two and either cause your back-end to crash or cause your front-end to expose, you know, secrets.

 

Yeah, your credentials. Yeah, the funny thing though is that RPC, remote procedure calls, which is really, we kind of discussed it in past episodes as well. It's kind of like a really old term. It goes back to the 80s. So this whole concept exists in order to again, avoid the fundamentals as it were. you're working in a

 

Yes.

 

low level protocol that exposes and highlights the fact that you're sending data over a network, the RPC strives to put a facade of a function call or procedure call on top of that. So you're working with backend code as if you're just invoking a function. like you would with other front-end code. And it's a really interesting question of, if I'm trying to obscure the fundamentals, it's kind of interesting that if I then don't make sure to understand the fundamentals, I might get into a lot of trouble.

 

Yeah. Yeah. And it's, I don't know, it's, it's fascinating. It's a, it's a point that, um, it's kind of funny because I feel like I talk a lot about, uh, fundamentals and web platform primitives and concepts like progressive enhancement. And a lot of these things are not part of the hype cycle, which sort of makes me feel like I'm missing something or, or why, you know, why don't I get it? But when I actually write code and I explore with these bleeding edge technologies, there's so much overlap there as far as I want to understand to the best of my degree how these things work and how I can implement the things that I already know and where it makes sense to separate those two like in some cases just because a framework can do all of these things for you like, you know You can do some react binding that maybe controls I don't have a good example, but but there's things that a framework can do for you, but It may not, it may make more sense to actually pull that instead of using the framework or library, pull it into its own little package, like JavaScript utility that can work across any JavaScript runtime and across any framework. So sure, there's probably not a lot of need for people to migrate the same application to multiple different frameworks or libraries, but it can protect you if you have code just written at the more primitive level. that you control that can protect you from either migration stories or even upgrade stories, like, uh, you know, going from react version X to version Y or something like that. Um, but yeah, I don't know where I was going with that. But yeah, getting back to the RPC stuff, it's really fascinating because I'm finding that where the overlap is, is you have a tool that lets you by convention define a server function. And then how it actually works is there's a transpilation step that takes that same file that has front-end code and back-end code and like separates them and... and basically creates an API endpoint for that RPC. Now RPC itself, Dan, like you said, is a very old concept and it's not even a technology. It's like a, it's a, what is it? principle or a concept.

 

A design pattern?

 

Sort of like a standard, like rest is.

 

Yeah,

 

Yeah,

 

Sort of

 

I

 

like

 

think

 

just.

 

a

 

a standard, yeah.

 

design pattern is probably the best term, I think.

 

Sure, sure. So it's basically a way for you to define a function that can be called from an application onto a different server, right? And in the web, the medium that we use to invoke that RPC function is HTTP. So what these tools are doing is allowing you to conveniently write code that in the source code will lives together, but in the compiled code actually. are completely separate, right? So you end up with a server function that lives somewhere in some deeply nested folder that the library author came up with and knows how to find. And that way, when you finally submit the form that this framework that you wrote in this framework and you invoke that function, it's actually sending an HTTP request to this endpoint that can then do the remote procedural call, call the function and come up with some sort of response.

 

If you

 

and

 

want to see another good example of that, Austin, you and I know it well with view. If you look at single file components, right? You have your template, you've got your script, you've got your style block, you know, if you so choose to use it. And I saw a really good blog post at one point that talked about how that worked and how the view behind the scenes basically takes that and says, okay, I got to split it apart here and I'm going to interpret this this way and this way and do different things with them. So it's... As you're describing your RPCs, I'm thinking, oh, that sounds a lot like Vue and its single file components.

 

Yeah, I mean, Vue doesn't handle the RPC part, but that is the...

 

This is a concept, the overall concept of taking one thing and splitting them apart into different parts. It allows you to do author things much more easily.

 

Yes.

 

Right. It's, it's a layer that allows you to do it, but behind the scenes it's doing all the work to split everything out,

 

The

 

you know, for you.

 

interesting thing that I see with the fact that effectively all frameworks are now, almost all frameworks, are now adding some sort of RPC mechanism, and you listed most of them, is that previously, when we implemented an endpoint for an API, we were fairly explicit about it. I mean, not always. Set server-side props is a sort of an API mechanism, and we were less explicit about it. But in most cases, you knew that you were implementing an endpoint, and you would reuse that same endpoint across various usages. I mean, if the front end needed to communicate with the back end, well, these are the APIs that you had available to you, and you might enhance them and add capabilities or version them or whatever. And now with these RPC mechanisms, we're creating a lot. I think we're seeing a pattern where we'll be creating lots of micro-API endpoints, you know, one-offs as it were. So I need to get something from the server. I'm not going to think about the various existing API endpoints. I'm just going to throw in yet another RPC implementation and just do whatever I need to get done. And it's going to create a lot of coupling between the front end and the back end. but that might not be such a bad thing if you're doing both in the context of the same application and the same framework. and the same version.

 

Yeah. Yeah, yeah. And this gets this gets kind of interesting, because it kind of hearkens back to my opinion, the topic of the progressive enhancement thing that library authors are kind of promoting, but at the same time, let's see, there, a lot of them are building tools so that you can implement progressive enhancement without having to think about it without having to understand all of these underlying fundamental principles, right, which is great because That's really the solution for solving things like accessibility or progressive enhancement, which could relate to accessibility, which is that you provide the tooling that makes it really easy for developers by default to follow the correct patterns and difficult to implement things incorrectly, whether they know what they're doing or not. So with progressive enhancement and these RPC patterns, yes, you end up with a lot of tight coupling, but depending on how the library works, it has to enable you to. also know what you're doing. That's hard to explain. I don't want to throw any sort of libraries under the bus, but I guess what I'm getting at is the things that I look for when I'm building applications with these, the things that are sort of table stakes is if you're going to give me an RBC endpoint and you're going to respond with a function that I can call that eventually produces an HTTP request, I need to have access to the URL. where that function is going to run. It can't just be some magic function that returns a component, a form component that I can just use and not actually see, be able to manipulate with the web browser primitives.

 

Why?

 

So I wanna be able, why not?

 

No, why? You're saying you... it has to be it. I'm asking why.

 

Yeah, so it has to have that because I want access to the, I want to be able to explicitly define what the form action is going to do, which has to point to a URL, which presumably would be connected to that RPC endpoint. And the reason why I want to do that is because I build my applications to support progressive enhancement. So that form needs to be pointed to some URL. So I need to know where it exists.

 

Yeah, but these days with some of these frameworks, all you just do is in the action, you just put in the function name and they just handle the magic wiring for you. So even in that context, you don't, you know, they kind of, by introducing RPC in, at least again, in the context of internal APIs, not external APIs, they kind of replace the concept of URLs or URL endpoints. with functions. So my question is, if I have a globally named function, that I exported function that I can import, or even maybe, like you said, implement even in the context of the same file, why do I need to understand the underpinning fundamentals of the network protocol and the way that data gets marshaled or serialized, deserialized over the wire. Is that really fundamental knowledge that I need to have? I'm not sure. I mean, what's your opinion on it?

 

Yeah, so that's a good question. Again, these frameworks are kind of new and these tools are new and I'm sure that there's work being done. So I don't want to disparage any specific one by name, but essentially I've been building applications and when I run into something that I cannot do myself, knowing how to build something from the ground up. So knowing if I wanted to build a form HTML and I wanted to submit it to a specific endpoint. I want to know where that endpoint is. And some of them do give you a function that you can return. And sure, you can just use that function reference anywhere then that you would in place of a string URL. Then that's just fine. Maybe I don't have to explicitly know where that URL is. But as long as I have some reference to it, treats it as a URL or a string, right? The reason being that, what was the problem that I had, was in order to create my own form from scratch and do my whole progressive enhancement thing, I have to have access to that URL. And if not, if it's some sort of abstraction layer and these libraries are doing some sort of, sort of a critical step in this HTTP back and forth, is this... serialization, that a lot of these libraries are doing some sort of serialization of the data that captures, I mean, closure is not the right term, but it captures all the data that it needs to send, and maybe how the function needs to be responded when it's sent to the server and then sent back or whatever. That library is handling all of the communication at the HTTP layer, which is some magic that I can't recreate.

 

I-

 

And at that point, I'm so, I'm so, I'm at that point, I'm so bought in and so dependent on the library doing it, doing its thing correctly, that I become a slave to their patterns and their knowledge and their upgrade paths. And I just like the flexibility of being able to say, okay, I'm going to take my, my business logic and you know.

 

I kind of, in that context, I think it's useful to make a distinction between, for lack of better terms, public and private API endpoints. Even if by public, you're still just using it within your organization. Public, I mean in the sense that it transcends the particular implementation. So if it's a public API endpoint, then you really want to just adhere web fundamentals. It needs to support, like if you're going to send data, you want to support post requests. You want to describe the API in a way that it accepts either JSON or form data or both. And that's basically it. And like in Svelte, you can now very easily implement these sort of things with just calling some function called post or get. all caps but if you're actually implementing RPC and using the RPC mechanisms like the server dollar whether it's quick or solid bling you're in your I think you're kind of intentionally and and Giving up on that. It's no longer a public API. It's a private API it's part of the implementation details and If you're going to replace your implementation, because it's wholly internal to that implementation, you're probably going to have to replace that endpoint as well. You're not really going to support it going forward, because in all probability, the way that, I don't know, for example, React, Marshall's data over the wire in the context of React Server Components is wholly different than the way in which Quick. Marshall's data for its RPC mechanism and it's just not going to be compatible with one another and I and I you know I recently, you know, people talk about how React Server Components is kind of bringing web fundamentals back and it's HTML and it's HTTP, but it isn't. The RPC mechanism isn't HTTP. Well, it is HTTP, but it isn't HTML over HTTP. It isn't even JSON over HTTP. It's their own. you know, protocol over HTTP. And, and it's, like I said, it's, it's fundamentally different than the protocols that other frameworks will use unless they explicitly decide to, you know, adhere to some new standard that the React team are inventing or something like that.

 

Yeah, this will be a really interesting thing to watch play out. Because the question becomes, as our PC becomes a larger and larger pattern in our applications, do we treat those as traditional API endpoints? And what should they receive, and what should they respond with? So Dan, you mentioned how. If you're using RPC, that becomes a private endpoint as opposed to a public one that you might consider like a rest API that, you know, receives and returns JSON. Um, I like to try and maintain, I, like, I, I want my, uh, HTTP requests to basically work with an HTML form if I can make it, if I can make that happen that way I can enhance it with JavaScript. include the RPC things and then the layer at which that HTTP request is made. I need to understand if there needs to be some sort of serialization or some sort of HTTP header that tells the backend what to do with the request. And then I need to know how that backend needs to respond and what it needs to respond with doesn't need to be HTML. It doesn't need to be JSON. It doesn't need to be some sort of serialized. some sort of serialized response that then the client that sent it knows how to deserialize and do some sort of action on. A good example of this is Solid Start. They have some really interesting patterns around how you can actually do server defined redirects. So that then when it gets to the client, the client automatically redirects the page. Well, that's all built on some of the fundamentals. And if you use their built-in tools, it's going to handle that whole life cycle for you. And you're gonna be none the wiser. But if you try and build it yourself, or recreate it yourself, you have to understand and pick apart what that HTTP request looks like going out and coming back. We shall see.

 

All right, I'm going to push this to picks just because I saw what time it is and we're well past being able to end on time. So Let's have AJ go first. AJ, what are your picks?

 

Let's see.

 

You can tell that

 

But.

 

AJ planned ahead because we never have picks at the end of an episode.

 

My

 

Steve?

 

my wife

 

Oh, you

 

and

 

ready?

 

I started watching The Mentalist and

 

Good

 

that's

 

show.

 

been yeah that's been pretty good

 

old show.

 

and there's probably some other things I could pick but I'm just uh I'm I don't know I don't remember what's what's been great since last week

 

Sounds good. We'll put that down for a pick. Steve, what are your picks?

 

Uh, no other, oh, the only other than the, the high point of the episode, the dad jokes, I will mention that Austin and I had a very similar conversation on views on view, uh, probably about two or three weeks ago, it's episode 214, uh, and it was just TNI and so I was able to get words in and, uh, so we talked about, uh,

 

Ha ha!

 

fundamentals and some of his recent blog posts that have been on hacker news. If you do search for Austin Gill on hacker news, you get quite a list of blog posts that he has had on there, some of them about the very things we are talking today regarding building HTML forms and file uploads and things like that. And they are in the show notes for Views on View 214 for the dad jokes of the week. The other day, my wife asked me, did you eat that pizza that I was saving in the fridge? I said, no, I ate it in the living room. She didn't appreciate that. The other night I tried making a nice candlelit dinner, but I think it would have cooked a lot quicker in the oven. And then finally somebody came to me the other day and said, why don't you write a book instead of just making these stupid dad jokes? I said, well, that's a novel idea. So those are my picks.

 

All right,

 

Very nice.

 

Dan, what are your picks?

 

Well, so my first pick is we just got back from attending the conference IJS London, followed by vacation in France. So my first pick is actually going to be France because France is beautiful. We visited certain parts that we've never been at. Lyon, Avignon. certain parts in the French Alps and so on. For example, we visited this beautiful village that's literally like stuck to the side of a mountain. I was going to prepare the name of its name, but then I forgot, so I'll try to throw it in by the end of my picks. But anyway, it's all amazingly beautiful. It's a wonderful area to visit, and I highly recommend it. So, and also as a part of this trip, I got to meet some friends, including, you know, a number of people that have been on this podcast in the past. So I met in London, I met Bruce Lawson. We had several years ago talking about semantic HTML and accessibility. He's a good friend of mine. I also had a really nice dinner with Ryan Corneato, who we had several times on the show talking about Solid and Signals and stuff like that. And during the trip in France, I got together with Joao Weiss from Google, who we had on our show talking about Core Revitals. So lots of fun had all around. So that would be my first pick. The second pick has to do with the topic of today's show about fundamentals. So in a couple of few weeks from now, we're going to have, I think, a joint episode with the team from React Roundup. And one of the guys there is Jack Harrington, who makes great videos about React. And one of the videos that I liked especially, I might have mentioned this one in the past. is one about React Streaming in depth. And what's really great about it is he shows how streaming now works in Next.js, how it works in remix, but also he also does kind of a DIY implementation of streaming. So you really see how the fundamentals of streaming work on the inside, which I think is a great thing in order to properly understand. how this technology works. So I guess we'll put a link to this video in the show notes. It's highly recommended. And now that I'm back in Israel, I'm back demonstrating for Israel to remain a democracy. So that's my third and final pick. And those are my picks for today.

 

All right, I'll go and then I'll let Austin go. I've got a few things to pick. The first one is, and you can't really see it if you're watching the video. Maybe if I bend my head down a little bit, you can kind of see a little bit of scratches on my head. I'm gonna pick it because I really like it, and then I'm gonna warn you if you shave your head,

 

Okay.

 

like I do, all right? I'd rather just have all the hair gone instead of that nice ring around the back. So I bought... I just decided I wanted to change up my shaving routine. And so I bought this, it's called the Bevel Safety Razor. And it's this heavy duty razor and you like clip the razor in and like the razor blade in and then you shave with it. And, you know, so I'm like, all right, well, I'm gonna try this out, tried it on my face. And it was so, it was so nice, right? And I'm like, this is awesome. I'm gonna do my head. And I cut my head up so bad with it. But I'll tell you,

 

I'm only

 

I

 

laughing

 

loved,

 

because I've been there, Chuck. I've

 

right?

 

been there.

 

So I really loved what it did to my face, so I kept it, right? I didn't send it back to Amazon and say, this is garbage, right? So if you don't shave your head, I highly recommend that you get the shaver. And if you do, then I recommend you use something else. The other pick I have, I skipped the board game. I'll come back to that. So the other... a shaver that I've used. I just decided to see if I could get an electric one that would do it because I'd seen

 

So I

 

a

 

do.

 

few of them that people seemed to really like. And I tried like some of the electric shavers that are made for your face on my head before and it either wound up pulling my hair or you know what little there is. Or it would like, anyway it was an unpleasant experience. And so I was like what the heck, I'll try it and I will send it back if it doesn't work. And these are made specifically for your head. They have like six spinning blades on them. And so, you know, you push it onto your head and it kind of contours to your head. And it's been so nice. And I'm kind of picky. I like a really close shave. And this one's like not all the way to the scalp, but it does a good enough job that I don't feel like I'm hitting bristles on my head when I rub my head. So I'm gonna pick that. Now to board games. Um... and I'm gonna look it up on Board Game Geek so that I can tell you the right game here. So we played this game, it's called Mystic Veil, and it's kind of a different game. It's a card game, it's not a board game, but it has like a bunch of different kinds of pieces. Board Game Geek rates it at 2.26, which means it's pretty approachable for casual players. I think we played it... through once with four people. And it was definitely a fun game. So the idea is, is you start out with your starter deck and then you can play as many cards as you want, but once you have three curses, then you're out and you basically just get a money piece and you're, you know, or a crystal and then you're done. But if you stop before you hit three or maybe it was four, revealed. then you can use the stuff on the card to get better cards. And they're not cards. What they are is this game actually comes with sleeves for the card. And so what you do is you grab one of the cards that you bought and you slide it in the sleeve with your card because there are three slots on the card that you can fill. And so some of them are blank and some of them have one slot filled and some of them have more than one slot filled that you start with. And so you essentially deck build by building out your cards, right? And so when you play a card then, you get all the effects on the card. So you can get the different kinds of currency that lets you get the different kinds of cards. So there's some other cards that give you just bonuses every turn, right? And so at the end of the game, you're trying to come out with the most victory points. Anyway, it was really fun, really, really fun. And so if you're looking for kind of a different mechanic on a deck building game, I mean, this is it. I really, really liked it. And so I'm going to pick that for my board game. And then one last pick. So, and this is something I picked up. You mentioned Jack Harrington. I was a guest on React Roundup a few weeks ago. And I asked him about his green screen setup and he uses this ATEM Mini. I think I got the ATEM Mini Pro. It's by Blackmagic. And it'll allow you to do the green screen behind you while you're running, while you record. And so I'm still playing with like where I stand and you know, my lighting and stuff, but I've recorded a handful of videos and I've been really happy with it. Um, the only other thing that I've run into and I'm still like tweaking, like I said, is that, um, if I wear a black shirt or a white shirt, it tends to pick up some elements on the black or white shirt. But if I wear like a blue shirt or a red shirt, then in front of the green screen, it works great. And you know, and so I can put whatever I want behind me. If I wear a black shirt and I have a dark background, that doesn't work so well, but that kind of makes sense when you really say it out loud. So anyway, I've been really happy with it, and so I'm gonna pick the Blackmagic ATEM Mini. And yeah, if you're looking to do some green screen stuff, check it out. But yeah, those are my picks. Austin, do you have some picks for us?

 

Before Austin starts, I just mentioned a village whose name I forgot, and I looked it up, so I just want to mention it. I'm probably going to butcher the French name. It's Maustière Saint-Marie. It's a village in Alpes-du-Haute-Provence in France, and it's amazingly beautiful. It's like a village, a medieval village stuck

 

Thank

 

to the

 

you.

 

side of a mountain. And if you can get a chance to visit, I very highly recommend visiting there. It's just amazingly beautiful. Thank you.

 

And you

 

Very

 

probably

 

cool.

 

get some good exercise walking up hills

 

Yeah,

 

and down

 

for

 

hills

 

sure.

 

all the time, right?

 

The people there really need to be in good shape.

 

Ha ha ha!

 

Just to get around.

 

Well, to get up the hill, to get down the hill,

 

Yeah.

 

nevermind, nevermind. Anyway, Austin, what were your picks?

 

Okay, yeah. So I work for a company called Akamai. I would be a little bit remiss if I didn't mention them because they are a great company with a really good product. They do content delivery network, web application firewall. We do the whole cloud hosting cloud computing thing now with object storage and I've had the chance to so We didn't get into a lot of the file uploads things, which was a shame because that's like the most recent deep dive series that I've worked on. And one of the things that we covered at the end was, uh, how do you protect your applications from malware? If you're enabling like public file uploads. And, uh, one of the products that was really cool to work with in Akamai was, uh, the malware protection scanner, which essentially allows you to block, uh, malware from even getting to your server because it gets scanned at the Akuma edge. So unlike

 

Mmm.

 

some ways of protecting from malware where it like scans file names or you have to do, you know, MIME type checking, all of those have some sort of, uh, basically unless you're actually scanning the file contents, uh, you it's really, really difficult to filter out malware. And, um, that was a cool service. It does have a file size limits. but it works really cool and it runs on the edge. So any bad file that it triggers as bad, never even makes it to your server. So that was cool. And I should also say that the work that I do for them is mostly, I consider myself, I mean, it's a developer advocacy role, but I kind of am more in a developer education role. So I get to write some content. I have a couple posts that I'll share in the show notes about... uh, uh, forms and file uploads. And mostly I'm not really trying to sell you any sort of products, but I do think that Akamai has, um, definitely in the CDN world and the, and the web application firewall world, I think it's like, uh, best in breed and the biggest companies in the world trust us. So that's been fun. Um, and I can share a link to get a hundred dollars of credit to any listener that wants. Uh, and as far as not. Well, actually, sorry, one more tech related thing. Uh, I've been working with solid start lately and it's been a breath of fresh air in terms of something that uses JSX, but isn't limited or isn't, doesn't have to do like the HTML four attributes or the class name thing, you can just do class and H and four, uh, that's been really nice as far as the templating side of things, they'd have a really good approach to, uh, the RPC solution. They have, you know, signals and. I think it makes it easy to sort of build in these, build with fundamentals in mind and be able to break out of their tooling or their abstraction where necessary or use their level of abstractions to like simplify your life. And yeah, I guess one non tech pick would be a stash, liquorice tea. Licorice Tea by Stash. Really tasty.

 

That

 

Oh,

 

sounds

 

that's

 

interesting.

 

interesting. I love licorice, so I probably need to give that a try.

 

I hate licorice, ironically.

 

Hahaha

 

I can't stand it, but this stuff is so good. And I'm

 

Dash

 

not even

 

T.

 

a huge fan of tea, so two things that I don't like, but somehow it's a magic combination.

 

Yep, I don't drink tea with like tea leaves, but if it's made from something else, that might be interesting. Anyway,

 

I usually

 

cool.

 

drink tea with a cup myself, but that's

 

Wow,

 

another

 

gosh.

 

issue.

 

more dad jokes. Austin, if people

 

Oh yeah,

 

want

 

where's

 

to

 

the

 

find

 

rims?

 

you online or see what you're working on, where do they find you?

 

Uh, yeah, Austin, gil.com that's G I L. Um, it's more efficient that way. Less, you know, storage, whatever. Uh, but yeah, I have all my stuff on there. I mean, I'm doing live streams, video series, blog posts, uh, Posting cute pictures of my dog on Twitter. So it's got everything on there.

 

So were you gale with two L's before Y2K?

 

Ah,

 

more

 

that

 

efficient.

 

joke escapes. More official, what?

 

Efficient. It

 

More

 

had

 

efficient.

 

to do with the date storage. You might be too young to

 

Yeah,

 

remember

 

no,

 

all

 

I,

 

that.

 

yeah, yeah. I was there, I remember the whole like ATM scare and planes flying out of, or planes, yeah, dropping out of the sky.

 

Well, it had to do with date storage and two year reverse support. Anyway,

 

there.

 

I tried. A for effort.

 

All right, well, we're gonna wrap it up here till next time, folks. Max out, thanks Austin for coming.

 

Yeah, thanks a lot for having me. It was a pleasure.

 

Bye.