Austin Gil is a Senior Developer Advocate. He returns to the show alongside Steve to talk about his articles. He starts the show by explaining what Vuetensils is. He also dives into his article, "TIL: You Can Access A User’s Camera with Just HTML". Moreover, they also talk about their perspective on what beginner developers should learn first if they're still starting out in the field. 

Hello everybody, welcome to yet another exciting episode of Views On View. I am Steve Edwards, the host with the face for radio and the voice for being a mime. And if you're watching on YouTube, you can see that. And I am flying solo today and we have a special returning guest slash host slash guest in Mr. Austin Gill. How you doing, Austin?

 

Hey, I'm doing well, how are you?

 

Good, good. So Austin and I are both here in the very wet and dreary spring Portland, Oregon, where it is cold and rainy and still feels like we're in winter, which is really great for those of us that are skiers because there's still a lot of good snow on the mountain, but not for everybody else. By way of background, Austin first, we had first had Austin on Views on View to talk about his little passion project called View Tensiles, and we can talk about that in a minute, and then and then decided I'm gonna do my own podcast. And so as far as I know, he's still been doing that. So how you doing Austin? If you want to give us a little background, tell us where you've been for the past couple years because things have certainly changed for you.

 

Oh yeah, it's been good. I, yeah, man, summer's just around the corner, Steve. It's coming, it's happening. Pedal Palooza is gonna happen for anyone that's in the Portland area. It's gonna be great, I'm

 

At

 

so

 

least

 

excited.

 

summer as we get it here in Portland.

 

It's, ah, camping and river floats. I can't wait.

 

Yep.

 

Yeah, so I guess, what have I been up to? Still working on the utensils. It is a little passion project that comes from, you know, I guess let's give a background on what it is, right? So it was a project that I started a while back that was essentially the result of working on several projects over and over in Vue and copying a lot of the same code and just like getting rid of all the styles from one project and applying new styles to another. So Vue Tensils is a collection of what I like to call naked components. Some people call them headless components, although it's not quite that because the headless component concept is, functionality and then you provide all of the markup. The goal with utensils is to provide a very bare bones as as minimal or tooling as needed, basically no styles, a bunch of components that have no styles, it's just bare bones, HTML and functionality. And the goal being that you have a foundation upon which to build completely bespoke, totally unique custom designs, applications. And the thing that's kind of the center of focus on the utensils is that, yeah, it doesn't have all of this extra bloat download or add to your bundle size or wrestle with strict CSS specificity. But all of the components are designed to follow best practices in accessibility. So yeah, it's essentially a project that I've been carrying around for a while and slowly upgrading. And since the last time we have talked, there's been a few upgrades. pushing to a version one because it never quite feels finished but there's a lot of things that are there's a lot of things that i've used on a lot of projects and feel very good and confident about and i guess the biggest changes have been things around how i've been working with forms

 

So a couple of quick questions real quick. I said quick, that's the Department of Redentancy Department. What versions of Vue do you support?

 

So it was originally written to support view 2 and it currently supports view 2 and view 3 There's a couple of things in there. There's like a couple of experimental things around composables, but for the most part everything that you interact with is either a component or a Directive or I think you can use filters still But yeah

 

And then in terms of, you know, bring the bare bones means you're gonna apply your own CSS. And the examples you have is for, you know, your standard CSS elements and, good Lord, I can't think. The words I'm looking for, your standard CSS like in a stylescript, but I assume you could also work with something like a Tailwind or Uno CSS or some other JavaScript library as well.

 

Yeah, so pretty early on, I mean, the challenge with creating components that are not entirely headless components is that as a component author, I want to be responsible for the markup and the functionality to make it accessible because at the end of the day, because accessibility is kind of the most important thing to me in this library and getting a head start on building out an application. you have to have control of the markup to make something accessible. And so when you control the output of the markup, it introduces a challenge for component authors or for library authors of how do you provide styling options, right? Because if you control the markup, then how do you allow people to inject custom classes like Tailend or UnoCSS or whatever? approaches that I provided with Tailwind, which is if you just like writing traditional CSS in a CSS file, cool. All of the elements on the page or in the component are going to have CSS classes available, whether they include styles or not. And that's kind of a little hook-in that people can use to target specific elements in a component and apply CSS rules to it. Or if you want to have your own custom classes injected into the component at the correct element in the markup, then there's sort of like an API for that through props. You can pass a prop called classes, and then for each element on the page, there's like a different key or property on that object. So, let's go ahead and do that.

 

Stupid mute button. So

 

Thanks for watching!

 

are you using like the adders, the built-in adders type of functionality where you can define something in a component definition and then it just passes it through? If you know what I'm talking about or is this

 

Yeah,

 

is more a specific

 

so that's,

 

target?

 

yeah, I think that's called like pass through props

 

Yes.

 

or something. It's basically a feature that not every JavaScript framework supports, like I don't think React does that, but there's a way to essentially have, well, what Vue does is when you have a component, when you've defined a component and you use it in a parent component and you pass any sort of props or attributes onto that custom component name, automatically be appended to the root dom node of the child component. Right. And what you can do is essentially tell view, Hey, I don't want you to pass through those props onto the root. I want to control where those get passed to. So a good example of this is if you wanted to create a custom input component, you probably want to allow for component consumers or parent components to be find all of the HTML attributes that would exist, that you would expect to exist on an input component. But if you're using a custom component, then the implementation depends on how those attributes get added to the input. So if your actual input, custom input component has a div as the root element, inside of which there's probably a label and then the input element or whatever, then you would want to actually inherit the attributes but only pass them to the input component, or the input element, sorry. Does that make sense? Mouth

 

Yeah.

 

blogging is really hard and yeah, it's kind of a nuance thing.

 

Yeah, for sure. I mean, I saw that just because my inertia running inertia project uses, I copied a lot from inertia's pink CRM demo application. And they have a whole list of different input custom components for drop downs and nabs and models and text inputs and so on. And they use that quite a bit.

 

Yeah.

 

Where they use the dollar adders, you know,

 

Mm-hmm.

 

class, for instance, and then pass that in. So then you just in your wrapper where you're calling you just passing whatever classes. that gets applied. So yeah,

 

Yeah.

 

it's a pretty cool little thing.

 

Yeah, it's a challenge because it really blurs the lines between what is an HTML attribute and what is a prop, like a,

 

Mm-hmm.

 

you know, library component prop.

 

Yeah, yeah, it took me a little while to get my head around it because I was trying to figure out how the heck are my classes getting into here? Oh, that's it.

 

Yeah.

 

Little reading of the docs. Cool. So before I forget, there's one thing I wanted to ask you about you had and we were going to transition and talking about using the platform as compared to always downloading a new library. But you had a blog post that went to like number one on hacker news a little while ago, didn't you? You were like world famous and I was going to see if I could get your autograph,

 

Uh,

 

you I knew you win. What was that about?

 

yeah, I don't know. I've had that happen maybe once or twice, but maybe the one you're talking about is that HTML, there's a mechanism in HTML that can essentially access a user's camera.

 

Yeah.

 

And so the way it works is I think you create an HTML input element and you give it, I forget the attribute name. Maybe I can look that up

 

Yeah,

 

really

 

I found

 

well.

 

it here. You can access a user's camera with just HTML.

 

Yeah, so there's an attribute that you can pass to the input element. And essentially what it does is where normally you would have a file picker that opens up the file picker UI on the operating system, which would likely be a phone because this doesn't work in desktop. But if you activate a file input on your phone, normally it opens up your file But when you can activate the camera, you can tell the device whether you want to capture the environment, which is the outward facing camera, or you want to capture, I forget what they call it, but it's basically the front facing camera and optionally audio like microphone stuff.

 

Well, it's the user attribute, according to your blog post, that

 

The

 

uses

 

user

 

the

 

attribute,

 

user-facing

 

okay.

 

or front-facing camera

 

Yeah,

 

and

 

yeah.

 

or microphone.

 

And so in this way, it's kind of interesting because it sounds a lot scarier than it is in that it's not like just HTML can start accessing a camera. It requires user interaction, first of all. So the user has to have knowledge that they're clicking something, which still, I guess you could hide a file input visually. And then two, of data coming from the camera is not passed to the HTML in the same way that the JavaScript API can work. With the JavaScript API, you turn on the camera and then you can see, like in the application that we're running right now, I can see through your camera feed because you've allowed camera access and now the JavaScript on the page has a way to read the stream and push the pixels HTML the way it works is essentially the camera opens for a moment and then once the camera captures a photo, then what HTML has access to is the location on the device where that photo exists, same as if a user were to select a file from their UI. So permission-wise, it's kind of the same. that there may still be security concerns depending on whether location data is transmitted with the file that the user selects or potentially if they forget that they left the camera on and took a photo or something and like, you know, show a picture of their kid or something. I don't know, but it's probably not as scary as it sounds, but still kind of interesting.

 

Right, so we'll put a link to the article in show notes. It's called on AustinGill.com, T-I-L, you can access a user's camera with just HTML.

 

Yeah, it's kind of interesting.

 

Yeah.

 

Yeah, and that kind of draws into, I've been going down this long winding path on learning. web fundamentals, which I hesitate to say it that way, because it sort of harkens back to the conversation around, you know, should new developers learn fundamentals or learn a library first? And I think that these sorts of fundamentals are not, maybe fundamental is the wrong word. It's like things that are built into the platform that are available. And it may be the JavaScript programming language, it may be JavaScript APIs available, of the browser, it may be things that are available in HTML. But these things that are, you know, foundationally built into the platform, but are also kind of weird esoteric knowledge that you don't necessarily need to build every single application, but are still kind of interesting and useful in the right use case. Does that make sense?

 

Yeah, I mean, use the platform as the phrase that comes to mind when I hear discussions about this instead of having to do something special on top of that to get what you want when you've already got the tools available there, right? Reinventing

 

Yeah.

 

the wheel, I guess, would be another great way to put it. I guess it depends on when you got into the web. We had this interesting discussion with Taylor Otwell. when we talked about Laravel and he was talking about trying to what to put in his docs because of who you see coming in, where it used to be people had all kinds of PHP knowledge and now you see people that are just in the front end and have no PHP knowledge.

 

Mm-hmm.

 

And my point was that, well, yeah, look at when people got in. So someone like myself, and this dates me, you know, when I first started playing with websites in the late 90s, you know, when Microsoft front page was still a thing and you know, and raw PHP because libraries didn't exist, WordPress didn't exist yet, Drupal didn't exist, you know, Node was, you know, a good 15 years away, jQuery wasn't even around, really, and so you had to know the fundamentals, right? You had to know what was there. Unfortunately, the fundamentals were pretty limited. The browsers didn't have a lot of the stuff that they knew, HTML didn't have a lot of the elements that it does now, CSS certainly didn't have a lot of the things that have been added over the years, so you had to know those. you got jQuery, right? So the biggest, the biggest thorn in jQuery side, and excuse me, in the JavaScript world was browser interoperability, because you had Microsoft trying to rule the world with Windows and Internet Explorer, you know, you had Netscape, then Firefox came on the scene, and then Chrome came on the scene, you had to do different things, and so the whole idea of jQuery was let's unify everything into one place where you can So jQuery became huge, humongous, it's still a thing out there quite a bit. But the browser started implementing jQuery into their own functionalities now, and so that's why jQuery is not so necessary anymore because they said, hey, we need to do this stuff for everybody without having used jQuery, and so they did. So if you get somebody that comes in, say later on, say 2010, 2012, I guess, maybe my years are off, a lot of these tools are out there So you just jump in and start using those right you don't need to know the fundamentals because there's so much stuff that does things for you and so You know all that to say I think it depends on when you come in and what you're using now me for myself I I did the you know, there's the classic Do you learn the language and then the library framework or do you learn the framework and then

 

Exactly.

 

the language? I did it the second way. I learned actually well sort of I did PHP time up through 2005-2006 that I got into Drupal and learned Drupal and through that I learned a lot more PHP especially some of the object oriented stuff. Later on I learned JavaScript through jQuery. I have one if you remember Rocks Publishing and if you go back that far Austin the Red Books I had a ton of their stuff. In fact this is Bookzilla I'll hold it up on YouTube beginning JavaScript you know and I remember

 

Oh

 

what

 

my

 

year

 

gosh,

 

this was published

 

look at that thing.

 

by Paul Wilton. Yeah, I mean, it's gotta be three inches thick. Not

 

probably

 

an exaggeration,

 

cut down like

 

this thing

 

three

 

is huge.

 

trees.

 

Yeah, and I remember actually conversing with the author, Paul Wilton, over email, and he had me some questions about what I thought about his book and that kind of stuff. But I tried to, and I got maybe a little ways in, it's like, oh my gosh, this is too hard.

 

Yeah.

 

I decided I'm gonna focus on backend development, and I did for a long time, right? a jQuery and then once I got into Angular, the original Angular in Vue, I went backwards and then started learning some of the fundamentals of JavaScript. Hopefully all that made sense. It was one of my normal diatribes. Your thoughts?

 

Yeah, I think so. And I think that that's an interesting conversation because people take strong opinions on both sides. And I just don't think that, I don't think that there's a clear cut answer for someone that's learning. If you want to build something and just, you know, you have an idea and you want to get it out into the world, then learn a framework or a library and then build out your thing. And that's going to get you like the fastest path complete. But then learning the fundamentals or the language or the underlying thing, having a deeper understanding of how things work is required, is necessary if you ever need to transition to a different framework or a different language. Those are transitional skills that are going to apply no matter what. And I think that's why so many people promote using the platform or because, you know, maybe they're in their experience, that's how they did it, or that's how they wish they would have did it, or something like that. I just think ultimately it's a dance where you have to participate on both sides.

 

Oh yeah, absolutely. I mean, if you look at, you know, say a view single file component versus a React component where React using JSX, you know, render functions, that kind of stuff. At the end of the day, you still got to have valid HTML for your browser. So if you don't know what you need to output, then you know, all the fancy stuff on top of that that helps you isn't really much good. Um,

 

Yeah.

 

the same with CSS, you know, you could use it Uno or Tailwind or Atomic CSS, or you could use Bootstrap or, you know, or whatever, those classes are just a layer on top of what you got to do. It's like a computer. What is, you know, all code compiles down in a binary, right? Zeroes and ones. And the same as with any framework, any CMS, any library, any tool. At the end, you got to have your basic HTML and CSS, and so if you don't know what that end result needs to look like, then you're, you know, you're flailing probably a lot more than you would be if you did know the basics.

 

Yeah, it's a weird balance of knowing how everything works, but then also giving yourself the freedom to not understand everything so that you can actually be productive.

 

Right.

 

Because there's more to learn. If you wanna understand how everything works, you're gonna need at least five lifetimes in this industry. You know, like

 

Right.

 

there's just no way.

 

Right.

 

The iceberg just keeps getting bigger and bigger.

 

Mm-hmm.

 

But anyway, I think that this stuff is fascinating and important. And the way that it's shown up in my experience or career is that the underlying, I do a lot with view, and I maintain this view library. But more and more, I find myself wanting to move code out of what the actual framework does and offers, what is built into the platform. And the reason being that, well, because lately I do a lot of things across different, I write a lot of code that's across different frameworks or libraries or tools. And when I'm just writing JavaScript, I can just copy it from one place and paste it into another. I can go from React to Vue, I can go from Vue to Svelte, I can go from Svelte to Solid, you know, and all of that just plain JavaScript works. And that kind of, that's kind of similar to some of the principles of good software design where you have clear and distinct contracts between different entities in the system, right? Where in one case I can create an API that's going to talk, translate between what's going on in Vue and how the Vue event system works or how props are being passed or whatever, and watchers and even from Vue 2 view three, but when all of those things happen in the context of view, I can use the view specific language. And then when I have a certain need that drops into just plain JavaScript, I can have a little bit of a translation layer between the two or communication layer between the two with a clearly defined contract and have a clear separation of concerns such that the actual JavaScript logic can work anywhere. And you can even say, you can even take that and apply it to have the same JavaScript run on the front end and the back end. And as long as you're not muddling some of the context specific details, like node or APIs that are only available in node or APIs that are only available in the browser or this and that, as long as you keep those kind of separate then you can still apply, you can still take that same code the underlying programming language, JavaScript, and run it the same anywhere.

 

Right. Yeah, I've been for static sites, you know, for your brochure type sites and stuff like that. I've moved over to using Astro.

 

Hmm.

 

We've had Fred Schott on here, one of the big Astro guys to talk about Astro. And what's cool about that is that the JavaScript that you write to query your data, and that's actually in your Astro template files is JavaScript. I mean, it's not You can drop in your view component or your rack component or your spelt component or whatever you want to do if you need something You know view specific But that's code that I could take from one project to another you know right and just plain JavaScript Fundamentals for getting my

 

Yeah.

 

data and for displaying it and passing it into my child astro component and so on So that's one thing I really liked about that You know what the guy that I read and I haven't really done much of his coursework is Christopher and Andy quote unquote vanilla JavaScript guy. And in one of his newsletters, he made the point not too long ago that he's had people that will tell him, you know, I wrote this JavaScript program eons ago, some site or application or whatever, haven't done anything with it and I'll fire it up and open it up and it works fine. Because it's not dependent upon, you know, library updates and all the things that go into maintaining a tool or a framework because it's just, you know, at its core, it's still basic JavaScript.

 

Yeah, yeah, and that principle of like code in frameworks that breaks because of upgrades or whatever, it's a real challenge. Like if you've had a project that you haven't touched in a year, and you open it up and you try and, you know, NPM run dev or whatever, there's that bit of stress that's like, ah, is it even going to run right now? And if it's not, nightmare of pain that I'm putting myself through in dealing with upgrades, right? So, uh, yeah, I think for me there's, there's a, a strong attraction to also shifting things towards, uh, more of the platform because it reduces the dependencies that I have, reduces the number of dependencies, which can help with that upgrade story. Uh, it reduces the number of dependencies with, which helps with, um, some of the performance story, right? If I can use fewer libraries in my project, then there's less code that has to be downloaded and probably less code that has to run for that bit of logic to work. So that makes me think, you know, the first thing I think of is form validation libraries. It's one thing that I think are not really very necessary. There's stuff that the browser provides for you that's built in. HTML has the constraints API or the constraints attributes, validation attributes. You have that built into the browser. You can do some things and have some very rudimentary. This field is required. It has to be an email. It has to be this and that. And if you try and submit the form, you get a pop-up that says, hey, this is invalid or whatever. And there's a lot of interesting things that come along with that. limit to that because at some point if you have a if your application is very very heavily dependent on very complicated forms with a lot of logic passing around that big hit that becomes a lot more complicated let's say even for something that's like a password a new user registration they have to put in their email and then they have to put in a password and then they have to confirm the password well in order for password confirmation to work on client the second, you know, the password confirmation field needs to be aware of the data within the password, you know, the first password field, which you can do with JavaScript, right? You can copy the value and put it into a regular expression or a pattern matcher on the HTML or something like that, but it gets more complicated. But I just, I personally just love... following or sort of allowing the platform to dictate the direction of my work, like start there and take it as far as I can go. And form validation or form, things to do with forms is something that I've fallen into very deeply as far as styling and JavaScript to go with forms and progressive enhancement. And that's a whole other subject to talk about. available. So yeah, I don't want to tell people how to build their applications, but I will say that it's something that I've studied deeply and have my own strong opinions about how I want to build things that I think are just... more resilient, it's knowledge that's more transferable to any project, and it works in more places.

 

In terms of forms, I mean, forms are notoriously difficult to deal with. That's probably why there's so many tools out there, right? Probably what the interesting dichotomy is probably one of the most used things on websites and it's also one of the most difficult to work with. You know, one thing I've learned is, you know, form validation on the front end is only going to get you so far because your code's in the browser, you know, people can monkey around with things. And

 

Mm-hmm.

 

from a security standpoint, if you have a backend that can do that for you, that validation for you, then you're much better doing it there and returning, you know, an error or something like that. It's not always possible, you know, especially if you're, say you're doing something like something that has forms and you're posting to an online CMS, you know, to a strappy or a contentful or sanity or butter, you know, whatever. Maybe there's some tools that they have on the back end that does some validation for you. But, you know, my... Laravel, you know, and using the controllers and all the functionality on the back end and requests, I can, you know, dial in my validation of my data and what's required, what's not very easy, and then just return that to the front end, whatever. But yeah, I think forms are difficult. There's a lot of tools, but in the end, you're only going to get so far, at least on the front end, when it comes to form validation.

 

Yeah, totally. And absolutely you should be valid. You should only be trusting validation on the backend anyway. And so if you can't trust validation on the front end because a user can bypass it or modify it or whatever, then what is the point? And I think that the point is as a user experience improvement, right? So that when a user wants to submit a form, they don't have to wait until the page refreshes, the back end and the back end validates it, the response comes back and then lets the user know all the issues that are wrong with the form, especially if they're gonna do that one input at a time, right? Have you ever done that song and dance where you submit the form, there's

 

Oh,

 

something invalid,

 

yeah.

 

it comes back and lets you know, and then you fix that and then you submit it again, and oh, the next field is also invalid and you have to

 

Right.

 

fix it for each one. And so that's where user experience is really important, by communicating clearly to users, messages, but upfront, while they're filling out the form, what is expected of that input field, letting people know which fields are required. And if you're going to do that validation song and dance on the backend anyway, I don't really want to penalize my user by adding a validation library to my code, to the code that they're ultimately going to have to download onto their device, right? Which if you're talking about users that are on their mobile data plans, costing them money. So. I, I, not that I don't see the point, but I think I have to go, I think I have to go a long way before I say it's justified, especially

 

Well,

 

cause it's built in. It's

 

right,

 

built

 

but-

 

into well.

 

I think there's a difference between validation and assistance is what I'm thinking about. So, you know

 

Yes.

 

when I think of validation I'm saying I'm thinking okay Is this number in the right format and we're gonna tell you if it's not, you know Is this a number versus string text because it's only a number field, etc and the stuff that I think that's still valid in the forms, but isn't a set of validation is sort of Formatting helpers like a mask thing for instance

 

Mm-hmm.

 

So let's say

 

Oh, yeah,

 

for instance

 

yeah.

 

so say for instance one of the ones I figured out I was stressing about I was rebuilding my app right now was a classic date picker. There's Viewtify or Bulmer or Bootstrap View or whatever. They'll all have date picker stuff built in. And I started looking in and realized, heck, the browser's got one built in. And it works great. I just use it. I have to look at my field, but you can just tell it that it's a date field and pass a couple other parameters in. And it gives you a nice date picker. You bring up, select your dates, click. It puts it in your format. You save it to your back end. You're good to go. JavaScript at all to do that. I think there's some other type of stuff with form fields. I think for some stuff you will need JavaScript. And then one comes to mind is maybe phone number formats, or maybe some date formatting, identifier type numbers, because you have unique requirements depending on localization, what part of the

 

Sure.

 

world. A phone number in the US is different than a phone number in Canada is different than a phone number in Mexico. That's that kind of stuff. So the kind of JavaScript that is useful is the stuff that you just type it in and it formats it for you. I love it when I get out of a site like that and I don't have to manually format my date or something

 

Same.

 

like that,

 

Yeah. Yeah,

 

right?

 

totally.

 

Versus having to put it in, oh, you started in the right format, you're missing a slash. Okay, thanks. You know,

 

Yeah.

 

so that kind of stuff I think is awesome as compared to, okay, is this a valid value for my backend?

 

Yeah, yeah, I think that, you know, in that regard, I think that backends should be pretty forgiving on what they can accept. So if it's a phone number and you know, you're in a US based area and you're expecting a 10 digit phone number and or what is it? I guess, no, I guess if you're in an international format and maybe you receive something you can and you want to assume that it's a US based number, you can add, you can append one ahead of it or something along those lines, right? You don't need to include the dashes or you can include the dashes or allow users to basically send anything that has 10 digits that looks maybe formatted including parentheses or not, including spaces or not, dashes or not, all of the different number formats, phone number formats that you can imagine. As long as you can parse that into something that the backend can detect as a legitimate phone number, just be less strict on the actual explicit syntax of it.

 

and do the cleanup and the stripping and stuff like that in your back end, is that what you're saying?

 

Yeah, yeah. I mean, you can do it on the front end as well if it makes sense. But a lot of the time, there's a surprising number of cases where the best input type is just a plain text field. You know? But yeah, that's a whole other deep dive story as far as user experience and accessibility and all this other stuff.

 

Yeah, for sure. I mean, even within HTML text field, you can tell it, okay, this is a number, this is supposed to be a number and give you your little arrows and you can count up or down, you know, if you wanna click instead of having to manually change a number, you can tell it text and yeah, date. And so yeah, there's all kinds of HTML stuff built in that will help you, may not be everything you need, but it'll at least give you a good start.

 

Yeah, and I have like a blog post series all about forms as well that I'll share. But the number input, even that has its own problems because you can imagine a form field like a credit card number or a social security number that appearance-wise it looks like a number. And so you might be tempted to make it a number field. But the problem with the number input by default scroll wheel mechanism that when you're hovering over it and you scroll up or down, the numbers will increment or decrement. And so you can imagine if you're filling out a form and you've put in, let's say, your social security number, and then you want to advance down the page and you're scrolling, but because you've selected that input with the mouse, the mouse is still there. So when you start scrolling, it decrements your social security number, but because it's and so

 

it.

 

you move the mouse, you scroll down the page, all of a sudden you've put in the wrong number, right?

 

Right.

 

So again, a good case for just having a text field, because at the end of the day, this data is going to be sent to the backend as text anyway. Every HTTP request, the body of that request or the URL search parameters are parsed as strings. So, yeah. Yeah,

 

So

 

we've

 

one of the

 

gotten,

 

other things you talked about... Sorry, go ahead.

 

just saying, we've gone way down into one of my passion topics, which is forms. And yeah, I don't know if we wanna keep going down that route, but.

 

Well, let's talk about your blog post that we initially talked about on how to upload files with HTML.

 

Okay, yeah, this is an interesting one. And kind of, well, before we get that, I should mention that it may sound a lot of the time like I say things like you just don't need JavaScript at all for a lot of things. And the truth is, well, for a lot of things you don't. But I believe strongly in the principle of progressive enhancement, which is, if you can build things with features that exist on the platform in HTML, use start there, use that first and build on top of that. And then whatever you need to do that you can do with CSS to make it an even better experience, then do it with CSS. So for example, with the CSS has selector, there's ways to do hiding and revealing certain content based on let's say you have a radio input and you select different options and based on which option is selected, you wanna reveal maybe more information on the page or not, you can do that with just CSS these days, right? You don't need JavaScript to detect which field is selected and then reveal its corresponding data. And then whatever you can do then with JavaScript, you should do with JavaScript. And then it goes up and up, right? Whatever you can do on top of that with view, go ahead and do with view or a library or whatever thing, go ahead. But only when it makes sense as needed. So where does it make sense for forms? I'd say doing the HTTP request. You can intercept the HTTP request, construct the request based on what the HTML has that the like a form would normally do if you hit submit, and then construct like a fetch request based on the form data. Also form validation. I think that there is a story where you can use JavaScript to do form entire library for it, you can base the validation logic off of what the HTML already has so that when JavaScript is available or if something hasn't gone wrong, there's not an error, there's not a problem with the CDN where the JavaScript lives, or the user's not on a slow device, or the user's not on a spotty network, or going at an airplane terminal, or going through a are the reasons why progressive enhancement is important, such that you build your forms so that they work with HTML and you can hit submit. And even on a slow network, if the page loads and it's just HTML and the user's really quick, they can hit submit and it'll still work. But then when JavaScript is available and everything works as expected, it can intercept the form submit request. It can do the logic to do the validation based on the HTML that's already there. if everything looks good, submit the request with using Fetch or something like that.

 

Yeah, I can remember back in the days of early browsers, back to Netscape and early Internet Explorer pre-version six, part of the reason for doing progressive enhancement, and I don't know if this is still an issue or not, is that users would go into their browser settings and purposely disable JavaScript. For whatever

 

Yeah.

 

reason, they didn't want JavaScript functioning in their browser, whether it

 

Yeah.

 

was security concerns or performance or whatever. and computers themselves were a lot less powerful back then. And so I don't, I doubt that anymore. I mean, it's really hard to use the web without JavaScript enabled

 

Yeah.

 

unless like, you know, you saying you progressively enhance them. So anymore it seems to be more of, like you said, your browser hasn't been able to download it because of a bad connection or for some reason the JavaScript isn't loaded in your browser itself.

 

Yeah, that's always kind of the first criticism of against progressive enhancement is that no one turns off JavaScript. And the people that do turn off JavaScript do it knowingly and so should expect certain websites not to work. And yeah, for the most part, I would agree that I don't think that we should build our applications to support cases where people are turning off JavaScript. But there's so many cases where JavaScript can fail, one of which happens to me all the time that I have like a very aggressive ad blocker or JavaScript blocker, basically third party JavaScript blocker on my browser. And so I have broken websites all the time. Now, maybe I am a little bit of a special case because of that, and that's fine. But the fact still remains that I think that focusing on progressive enhancement has made me a better developer, that they're going to work. And I find I have much fewer bugs. There's much fewer cases where my application experiences bugs when I've built it in such a way that it can just fall back to at least a minimum working experience in the absence of JavaScript. And I can share a couple of links to some of those articles as well. One of the numbers that I saw that I think BBC, website or like their engineering team did some research several years back at this point, but they found that 1.1% of their users or potentially page loads had experienced a JavaScript failure. only 0.2% of those users actually had JavaScript disabled. So the 0.2%, maybe not a big enough thing for you to worry about, maybe check your metrics, and if you have a ton of users that do match that, okay, maybe it's worth fixing, right? 0.2%, I'm not so worried about. 1%, I definitely am. And it's those 1%, the other 0.9, it's that 1% that are made up of people that experience, yeah, maybe ad blocking, bad connection, maybe they're in an airport terminal or on the train or whatever, so many more people are browsing the web, the majority of people are browsing the web on their phones. And if you're out and about doing your thing, you can't really rely on a good network, especially outside of places like, I mean, let alone outside of places of the United States, inside the United States, you still can't rely on it. So, yeah. off on

 

Oh no,

 

different things.

 

oh no, that's good. That's fine. Let's go, so let's do this. Let's go back to the initial premise about using the platform.

 

Mm-hmm.

 

So going back over previous years and looking at enhancements that have been made both to CSS and to HTML, and maybe JavaScript to a certain extent. JavaScript seems to, in the browser at least, seems to evolve much more slowly than HTML. Well, probably HTML. a little

 

I

 

slower.

 

think.

 

CSS is the one that's moving so fast it's hard to keep up with, right?

 

Yeah.

 

I know JavaScript, HTML tends to be much slower. I've heard someone say one time it took 10 years just to get the main element added.

 

Yeah, that's a good thing.

 

But yeah, yeah, it just means you're bearing thorough for sure. But what I'm getting is I'd be curious to see what you see as things over the past few years that have shifted or have been implemented so much that now you can use the platform where before you would have had to use a library or framework or a tool to do from a web standpoint.

 

Yeah, I think that the first thing that comes to mind is a lot of the progress that has been made in the CSS world. Just because, you know, like HTML does move slowly. And I think that's a good thing. And a lot of HTML's movements have been towards semantic things.

 

Mm-hmm.

 

So a lot of the big shifts that HTML got were in those semantics,

 

Mm-hmm.

 

which I don't think you can really replace with JavaScript or CSS anyway. So know that, well, anyway, I think that the best candidate is going to be CSS because if you've been doing this, if you've been doing the web dev thing for a while, you know, like there's a

 

Yes.

 

lot of things that were impossible to do with just CSS, even having a column of elements that are like the same height, right?

 

Yes.

 

Like that used to require JavaScript to have a column of elements and like inherently they have different height, but making their like the same height or something like that. I mean that's so easy with CSS grid or flex these days.

 

Oh yes. Oh man, nightmares about floats and there's a clear fix and

 

Yeah.

 

you know all the little

 

Yeah.

 

special things you had to do just to get your layout to be just... Oh man, that gives me nightmares. I'm just

 

Yeah.

 

thinking about it.

 

Also, the has selector is awesome and can do a lot. I know that sticky position elements is something that also used to require JavaScript that now you don't need. And a lot of that JavaScript depended on very not performant approaches to adding event listeners to the scroll position of the page. And so you just end up thrashing the DOM, and it was just terrible. CSS can just do it without batting an eye. So there's that. I think also there's going to be features that have improved from the JavaScript perspective in terms of how the TC39 committee responds to community use cases. being the most predominant library that was used at a certain point. And almost everything in jQuery was adopted by JavaScript because it was able to pave the cow path, you know, that then everyone was using. And that influences what we actually end up adopting. And that's important for things like TypeScript today. I personally am not a fan of writing TypeScript files. I really like having type definitions in my JavaScript, though. So I use JS docs, but I'm using TypeScript under the hood to do all the type checking, whatever. But TypeScript is important because it is influencing, potentially influencing the direction of JavaScript as far as what we're going to have available in terms of potentially decorators, which gained a lot of traction and then kind of not so much, or potentially type definitions TypeScript through the comment blocks or whatever. That is a proposal that's out right now. And these things are important because we can see as a community what people are going to gather around and really use and it becomes ubiquitous. And these are external things that are not part of the platform that do not have to become part of the platform until we can see that the community to bring it into the platform, whether that's the browser APIs or the ECMAScript language or whatever.

 

Yeah, case in point, there's a couple of thoughts coming to mind here, but case in point for one, I think from a JavaScript standpoint, one that's being worked on and I don't know the current status of it, it's the temporal API, right?

 

Mm-hmm,

 

Date

 

exactly.

 

and time management. Because for so long you had things like moment and then that was just huge because it was an all or nothing thing in terms of importing with moment. And you got stuff like date functions and day JS and other smaller, more slim down versions that were a little more performant. But the idea of the temporal API is to be able to replace those so you don't have to use them anymore. You can just use JavaScript. I don't know how well that functionality, because those libraries did a lot and I'd

 

Mm-hmm.

 

be curious to see how much is actually implemented in the JavaScript API. But that's one example of things being added that have usually required libraries in the past. But my second thought, and I'm curious to see your thought on this, if you'd seen this as you talked about TypeScript. types, what was the precursor to TypeScript? Formation?

 

flow.

 

Flow? Yeah, something like that. You know, and the idea is that typed is better because you can catch our errors ahead of time and so on and so forth. And it's still one I've resisted. I don't know if so much resisted is not taking the time to really sit down and learn it. You know, there's times when I have to use it because something I'm using already uses it. But, you know, that was the way TypeScript's dominating the world, the JavaScript world. that Sevelt just got rid of it. SeveltKit just

 

Yeah.

 

removed TypeScript from it because they figured within there are enough built-in tools and capabilities that they don't need that extra layer of stuff on top of it. And I start seeing other pushback, I've seen some stuff on Hacker News lately, where like, well sometimes having a dynamic language is good and not having everything curious to see where you fall on the TypeScript side of things, especially with some of these more recent developments.

 

Um, yeah, I mean, the recent developments really haven't shifted my opinion. Um, I was introduced to TypeScript learning Angular and I hated learning both at the same time.

 

Angular

 

And I

 

2,

 

think,

 

because that was

 

uh,

 

the one that required Angular TypeScript, if I remember correctly. 2 plus.

 

Yeah, I would have been not. I mean, I don't know. It was a couple of probably three years ago.

 

Hmm.

 

Um, but I think that I don't like the idea of having TypeScript in a project that I am in charge of because I don't like the idea of raising the, the bar for folks that want to get started. Like junior developers that are going to be joining the team. I don't like people having to learn maybe two things or three things at once. Right. Three things being. One, they have to learn potentially JavaScript as a programming language. Two, they have to learn TypeScript. Three, they have to learn my actual code base. And four would be if I'm using something like Vue, right? So that's just more things to learn that aren't really necessary. Now, TypeScript itself offers a lot of benefit. I like having strongly typed. I like having types in my JavaScript. And the other reason for that is once again, because I'm a web development educator, I have to write my code in a way, or I like to write my code in a way that in my project, it's going to look the same as when I copy and paste it into a blog post, which is going to look the same if someone else wants to copy that code and paste it into the browser or paste it into node or whatever, it's very, it's very, what is it, or, you know, can be, It can move in different places.

 

Isomorphic.

 

Yeah, isomorphic, yeah, there's a word that I'm thinking of but I can't think of it.

 

That was the one I was thinking of where they talked about the benefits of Node.js because you could use the same JavaScript on the backend and the frontend. And so it was all,

 

Yeah.

 

you know, that's the only phrase that comes to my mind.

 

Yeah, portable. It's

 

There

 

very

 

you go.

 

portable.

 

That works

 

Yeah,

 

too.

 

yeah. But yeah, aside from that, you know, I think everyone has their own preferences. It's very, it's a lot easier to get started using TypeScript these days. Yeah, I think TS node just makes it super easy, or if you're using Dino, it's built in. And

 

Right.

 

hey, that's great if that's your thing. JS docs works great for me. I prefer having the syntax a little bit more separated is generally like up above the function or variable definition and not in line with it.

 

Thanks for watching!

 

There are cases where JS docs is really ugly to get something to work. And you know, it's just nothing's perfect, but it works well enough for me. But I think ultimately, if the type proposal comes to JavaScript anyway, then you know, my stance is that TypeScript the future. I think TypeScript is the present, and it's a very important tool for us to have in the ecosystem, particularly because it does help, it does provide a platform to move the language forward that is not the language itself. And it can, you know, again, sort of influence the direction of the language without committing, without the language having to commit to it, to these changes. as an option. Yeah.

 

Cool. All right, so we're hitting up on time here. So before we move to picks, anything else you wanted to touch on real quick?

 

Yeah, I should probably just bring it back to the Vue Tensiles thing since it's a Vue podcast and we started there.

 

Ha ha ha.

 

If yeah, I would encourage anyone to check it out. All the code base in there, like if you want to take it and sort of fork it, the documentation, all of the documentation pages link to the source code for the respective component. And the components, the source is designed to be something that you can kind of copy if you don't want to have a dependency on the library. Of course you wouldn't get upgrades or updates in that case, but they're pretty few and far between anyway. And there's a couple shared functions that you would have to rewrite like a random string generator or whatever, but for the most part it's designed to sort of just be self-contained. where it can. A lot of the times these things around forms and inputs where you need that validation, you want to know if the input is invalid, you can do that in the web platform very easily. But Vue Tensil's components do sort of make a nice convenient wrapper around that that's lightweight and you know pretty easy to implement and is very very close to what the platform offers.

 

Cool. Yeah, the URL for ViewTensils is a very difficult one and hard to remember. It is viewtensils.com. We'll place

 

Yeah.

 

a link for that in show notes, as well as some of Austin's other posts that we talked about, such as the file uploads with HTML, using your phone, excuse me, your camera from HTML, and some other ones. So those will be all there for your accessing pleasure.

 

Yeah, so the file uploads thing is actually, that's actually just the first post in a series.

 

Okay.

 

It's about basically all of the things, all of the steps that I would follow when dealing with file uploads. So it talks about how to do it with just HTML and then how to enhance that to use JavaScript. And then when you're sending file uploads, you have to find a way to receive them, receiving multi-part form data essentially. And that post talks about do it in Node.js, but it is in a Nuxt.js environment and kind of follows that principle of do the Nuxt specific things and separate or abstract the Node specific things. So it's also portable. And then we go into optimizing object storage or cost using object storage, optimizing performance with the CDN and doing malware scanning. And that's what I've been working on lately. And it's a lot of fun and a lot of deep dive stuff.

 

So it looks like the CDN and malware scans ones aren't done yet. You still working on those posts?

 

Uh, this, that's correct. They're, yeah, it's my current work in progress.

 

Cool. Yeah, the links to all of those future posts are on this first one about uploading files with HTML. Think of it, for those of you JIRA ticket people, think of it as an epic with different tickets.

 

Yes.

 

Sorry if that traumatized you remembering those things. I know it does me. Okay, so with that, we will move on to pics. Pics are part of the show where we get to talk about things that we want to talk about that may or may not be tech-related. whatever have you. I always call mine the high point of the week in terms of my my weekly dad jokes. Didn't really have anything else to pick today so I'll just go with the dad joke. So let's go with the simple one. So what did the left eye say to the right eye? Between us, something smells.

 

Oh, gosh.

 

Right, right. That's that's old school. That's very basic. So last night, my wife and I watched three movies back to back. A lot of binge watching, you know. Fortunately, I was the one who was facing the TV.

 

That one got me, all right.

 

And then finally, pigeons must be extremely wealthy because they have no problems putting large deposits on expensive cars. among other things.

 

You know, I, every time I have a terrible joke, I think of you

 

Ha ha ha.

 

and I come up with a lot. I have a very low, I have like no filter for terrible jokes, but

 

Yeah,

 

yes,

 

that's sort

 

been meaning

 

of, that's

 

to send

 

my legacy

 

you some.

 

is if you have a bad joke, think of Steve for sure.

 

Yeah.

 

Right? Yeah. So anyway, what do you got first for picks?

 

Uh, yeah, well, like we said, there's a lot of, I mean, I'm, I don't know what to call myself. Technically I'm a developer advocate at Akamai. And I'm fortunate that, you know, a lot of my focus is on educating developers. So I just call myself a developer educator. And as part of that, there's a lot of places that I post my content, my website, all of the links that we talked about today, there's a lot that are related or relevant to forms that we'll share. There's yeah, that view utensils thing if people want to check it out. And I also do want to give a shout out to, um, Akamai just cause, um, it's a, well, not just because, you know,

 

They

 

I work

 

pay your

 

there.

 

check. They

 

Yeah.

 

pay your money.

 

But,

 

Ha ha ha.

 

well, yeah, not just that. Um, but because I work there, uh, I do get to see some of the cool stuff that we're working on. And we are, uh, pushing out our new, uh, cloud computing platform, which, uh, Linode, which is a really awesome company,

 

Oh, you did, okay.

 

has great products. And as a result of now having this whole Akamai connected cloud, which is the Akamai Edge, the CDN side of things with the web application firewalls and malware scanning and all of this cool enterprise level edge compute stuff, and connecting that to regular cloud computing, or not regular, but traditional cloud computing, I'm really excited to see how this builds out to be the most distributed cloud computing platform that also incorporates enterprise top-level edge technology with what you would think of as traditional cloud technology, like managed databases and VPSs and all that. It should be really cool. So I guess Akamai.com would be the thing to learn more about that.

 

Now, Akamai at its core for where it started out was, if I remember correctly, from my Drupal days, is it's sort of a video processing platform. Is that right?

 

So Akamai does a lot. I think they originally originated the concept of a CDN, a content delivery network. And so with part of that, CDNs have evolved a lot since, you know, over the 20 years that the company's been around. So that was hosting static assets as close to users as possible. But then as technology evolved and there's been a lot of need for, yeah, video streaming, network and some of the best technology around taking video content and streaming it to the user at really high quality rates. I can't speak too much to that because most of my experience is on the edge compute side of things. But yeah, there's edge compute, there's static file hosting, there's the web application firewalls that are a great way to protect your application as well. So it's been cool and I've been there just over a year and I'm see how it continues to evolve and grow.

 

Cool. So Akamai is the pick of the day.

 

Yeah.

 

Mr. Gill. Alrighty, so if people want to get a hold of you or find out what you're doing or give you money or berate you, where's the best place to do that?

 

If you want to give me money, I'd encourage you to send that money to some open source maintainers, aside from myself, because I do that for pleasure. But yeah, there's a lot of people out there that we are building really cool projects thanks to their efforts, and they deserve to be recognized. And if you just want to hang out with me and learn and watch YouTube videos or hang out on live streams or read blog posts, then austinguil.com is a good place to find me. Thank you. Bye.

 

AustinGilthought.com. All right. With that, we will wrap up this episode. Thank you, Austin, for coming back, and I'm glad we didn't scare you away from your previous visits. Always nice to have a fellow Portlander on the podcast with me, even if he's a transplant from San Diego.

 

Oh yeah, this has been great. I really enjoyed the show, so it's been a good

 

Alright,

 

conversation.

 

yes, good times. Alright, thank you for listening and we will talk until next time on Views on View.