Our Web Dev Wish List

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talinski and Wes Boss.

Welcome to Syntaxel Podcast with the tastiest web development treats rid. Out there today, we've got one for you.

We are going to be calling our web dev wish list or Slash ugh just do it for me. This is something that's come up in the past, I don't know, a couple months rid. Where Scott and I were like, why doesn't it just do that instead of us having to fuss around with it and to take care of these things? You rid. You know, sometimes you talk to someone, like, make sure you do it this way because of this way. And you're like, well, like, why doesn't isn't that just the default? Or why doesn't it just do it that way in the 1st place? You know? Rid. So we are sponsored by 3 awesome companies today. Linode, Cloud Hosting, Century Era Exception and Performance Tracking, and FreshBooks Cloud accounting. Talk about all the way all of them partway through the episode.

With me, as always, is my complainer in crime, mister Talinsky.

Rid. Hey.

Yeah. What here here's a fun little story about me complaining. I got voted the biggest complainer in, like, 6th Great, and I've been thinking about it ever since.

Oh. What happened? So so it's like, what? What? What? What

are you talking about? I didn't believe that they would let that happen, the teachers.

That's what Courtney said. Courtney was like, what? What are you talking about? Yeah. So I I, I never thought I was a big complainer. Maybe I was. Who knows? But, like, after that moment In the 6th grade, I was just like, well, I need to change my ways here if I am if people see me as a complainer. I don't wanna be a complainer.

But here we are gonna be complaining about some stuff. So I guess that's, that's whenever we're at. We're back at it.

Rid Yeah. 1 of my one of my best friends got voted the ladies man. That's what he got voted as. And I got voted as the biggest complainer rid. And this is great. Yeah.

Oh, man. That's good. Alright. You wanna kick it off there? Yeah. Let's let's kick it off. These are things that, You know, we I think I think maybe we should preface many of these. It's like we often understand why some of these things don't work the way that we're going to be saying today.

Sometimes we will do episodes like this, especially about, like, react stuff, and people will be like, well, actually, you do it this way because of this. And it's like, yeah, we we know.

But that's not the point here. The point is is that we just wanna complain about some things or say that they should be different.

So and some of these things are actually changing too. Some of these things are coming. So for for instance, the first one that we're gonna do is HTML stuff. And the first one I wrote down here is custom and automatic page transitions, And that's something that's coming. In fact, that's something that I think is going to really change how we do a lot of sites because if you ever worked in any sort of native context, Like native app development, you have the the this the way of, like, working in navigation is, like, you have a stack, and you're pushing and pulling things from a stack. And You can tell it what type of animation or what type of interaction this thing is, and the native app just kind of does it. That's if you want to do that. And so the fact that we don't have those types of primitives on the web is that means everybody's using their own thing, and they're largely having to pick up a whole front end framework to do so Just to do a a page transition, which even then is still difficult to work within the routing context on the web. So, rid. Custom and page animations and transitions that work with tools we know and love, gotta have it. That's something I I'm just very excited for, and, hopefully, The API ends up being something that we all want to use.

Next one you have here, and this is something that I just realized a couple Weeks ago. That is not actually an issue. So, it says date input translate to JavaScript date. So if you have a rid. JavaScript input and you'd use dot value, you get a string from that. And same thing with the number input.

A dot value from a number input will return you a string and then there you require a little bit of extra to parse it into a date or a number.

But I I don't know if you know about this, Scott. I just learned it like literally 2 weeks ago.

There are properties on, on the number and date inputs called dot value as number and dot value as date. Rid. In the yeah. What? Yeah.

What? Really surprised as I was. It like this is like rid. Like like 5, 6, 7 years old. Like as old as the inputs are.

So let me find you the tweet that I I'll link it up in the show notes here. You mean I've been writing,

like, custom functions to do this instead of just using bind for no reason.

I just put it in Slack.

And this is really cool because it is also a setters, Meaning that you can set, a if you have a data object, you can set the value as date to be a date and it will you don't have to turn it into a string first. And same thing with number, although you can do that, it'll course it. But this is like if you're using TypeScript, it'll yell at you and this will go straight up. So I had no idea. Wow. Neat.

That's fun. Yeah. I like this. Yeah. Very cool. I don't know why. And, like, I tweeted it. And

rid I retweeted it, but I must not have read it. I must have just retweeted it.

233 retweets, like, is is popular. Like most people didn't know this. I was very surprised that, I'm very pleased to find it. I retweeted it and I still didn't know it. So. Yeah. Rid. Yeah. Interesting. Along with that, you have date pickers with better inputs.

Come on. I wanna be able to style the date picker and make it not crappy. Right? Yes. Rid. I wanna that's a whole thing about these better inputs too is that you end up getting better inputs occasionally, or we have some nice inputs, and then they're a pain in the butt or impossible to style. So that's what I want. I want a day picker input that works and is nice. But then if I wanna make it look personalized and I wanna change the CSS, I want it to be easy. So I wanna be able to customize and control my inputs, but I want them to function well without me having to write the function for that. I don't wanna have to write A pick this date between this date, and I get it. There are ones coming, but I want them to be supported. I want them to be everywhere. I want them to be nice and easy to use. Yeah. They look like they're from Windows 95 on half the browsers and they're tiny.

Like, have you ever tried to use the arrows on the input Type equals number?

Yeah. Like, it's like arrows for ants. What's the point of using? What is it the point of the numbers even existing? Right? Who's gonna use that? Yeah. Yeah.

Totally. I hear you. Another one here would be, smooth and animated drag and drop.

So we have like a kind of I would say, like, kind of a drag and drop API in HTML. The drag and drop HTML API is like it it It gets you halfway there. Right? You can drag things with it, and it just doesn't look good. I don't think, I don't think anybody's implementing the drag and drop API as it just is and being like, alright. That's it. End of the day.

Because most times we have drag and drag and drop, you have maybe, like, a list of things. And when you hover over things, the items are doing their little flip animations or, you want more control over how things look or you just wanted to look nice. But the the drag and drop API out of the box, I think, Could probably be, and I get it. You can customize this thing, so don't don't at me with this.

But I think it could, out of the box, be nicer.

Rid. Just just out of the box. Out of the box, be nicer. That's that's pretty much exactly what I want out of this thing. I want I want something that That works well and looks modern out of the box without me having to write it each time. Yeah. I, I built my own drag and drop thing for my TypeScript course coming up. And I was like, I wonder how hard it is to write drag and drop. And we did a whole episode on it, and

There's a lot of edge cases. And then also by default, it's not accessible.

So I had to write all of that as well, all

the keyboard functions and all the announcing when things get reordered and whatnot. So, yeah, certainly that is not a primitive built into the browser at the very basic, A very simple drag and drop that doesn't even feel good, is, you know, quite a bit of code.

Yeah. Yeah. That's what I want. Ready. Easy and feels nicer. That'd be great. Next one we have here is JavaScript.

These are things that Why are they like this? I think the big one for me is the TypeScript interfaces are faster than types.

I saw some stats the other day that they're like, Like significantly faster to compile than types.

And like that's that's the reason a lot of people say use interfaces over types. And I was like, well, why

is it that way? And obviously, again, I think we have to keep saying There's obviously a reason behind it, and maybe they will get faster at a point. But when those types of things start to dictate how we write our code, I start to question, like, why why is it happening this way? You know? Why is it happening this way? Shouldn't you pick the the better one for the thing rather than talking about Which one is faster? Yeah. And on top of that, I feel like there should just be one that does every right? I think 2 of them. Right? I mean, this is like, Why do we have 2 things that kind of do the exact same thing but kind of don't? And then there's, like, a you get their whole table of all the things they overlap and don't overlap with. It's, like, This is pure overhead and having to learn both of those things. I was making the video for the

types versus interfaces, and it's just all like They do the same thing. But in this one use case here and there, and it's just mostly edge cases here

here and there. So and some people will use 1 and some people But we'll use the other, and the syntax is different, but you just gotta learn them both. And you gotta know the edge cases and the reasons why.

It's like, come on. Why? Yeah. Why?

Yeah. Yeah. Why? Why? Why? It's true. Make 1. Just make 1.

And like, maybe I'm not totally understanding it, but I don't see why You couldn't just make all both of them do

each one. Yeah. If we're dumb guys here saying this, like, do other languages have Two things for the same thing. Like, our other type languages, do they have both of these concepts? And if so, like, is this how it is elsewhere? Because it just feels weird to me. Rid. Next one here I have here is not TypeScript based, but it's, window dot request animation frame. Basic basically, this rid. Method, tells the browser that you wish to perform an animation and request the browser, calls a specified function to update an animation before the next paint. Basically, this thing allows you to control how the browser paint. So that way, you can have better FPS in your animations.

And anybody who's done anything with animations to the browser has to know all about request animation frame.

Here's my argument.

Why? Why? Why? Why can't the browser just do it for me? I'm gonna tell this thing to animate. Why can't the browser say, oh, you're animating something? Let me just do it when I'm supposed to do it to make it more performant. I get it. There's there's gonna be reasons why. Don't don't actually have me about this.

But, you know, rid. I think I do enough animation stuff that I just would prefer not to have to worry about it. Yeah. Like, where's the do it? As I guess you could also code this, but like, where's the

rid. Update this as often as possible, you know, like, because make it match for me function. The people that are are listening. So there's like kind of if you're trying to animate something, you can set interval, and set interval will run as often as you tell it. And then you have request animation frame, which is it will run at the next paint. And what that it's kind of a recursive function. So you run it once. And at the bottom of that function, you say run it again the next time before you paint, and then it will run the next time. Then again. It will call itself again and again and again. Right? And that is better because you are not Unnecessarily running a function more times than the browser can possibly paint. If you're only running 60 frames per second, You're not running this thing a 100 times per second, unnecessarily

so. Right? So that's that's the reason behind it. But, yeah, it seems like there could be a better API for that. I agree. Yeah. Just do it for me. Okay. This is this is not practical. I'm a you know, I'm a before anybody, you know You know, it comes out with the technical reasons for these. It's like I want a button. Make a button, no bugs, extra fast website, go. You know? Let me just do it for me.

Extra.

Rid. No bugs.

Next one here is custom elements and web components with data binding and props. That would be rid. Data binding native to the browser would be really, really sweet. And what we mean by that is you put a variable in a div rid. And when that variable updates, the div will update with that new value. Right? Very similar to how every framework works right now. Rid. It'd be kinda cool to have that not even necessarily in web components, but just in vanilla JavaScript. I would love that. Yeah. You know, data binding is something that makes working with forms in JavaScript just so much easier.

The fact that somebody, I think in the Svelte community was like, what do you use Form libraries and the answer is like, I don't know. I mean, I have 1, but you don't have to use it because forms are just easy when you have data binding.

We have a value.

We wanna interact with that value in JavaScript.

We just want to say, hey, value. Anytime we reference you, reference the value in the, input. Bingo bango. Just do it for me, please.

Next one here would be, this is actually very funny. And, again, also not practical as many of these aren't. But like authentication.

I mean, everybody's gotta do authentication. So many projects have to do authentication.

Kinda feels like there could be a better browser API with that, considering Many of us log in to our browsers with accounts already. You have accounts. You have emails addresses set up. Like, I get it. There needs to be a data. That data needs to be tied to a user. I wrote my own auth system. I get it. But at the end of the day, it'd be kinda cool if there was just, like, permit is baked in to allow you to authenticate really easily. Who knows what that would look like? I have no idea what that would look like.

Rid. But, hey, it'd be kind of fun. Right? Something you gotta do in every project. There like, there is primitives for, like, biometrics and, like, fingerprint and,

rid. Face ID, those are built in. Right? So maybe it'd be kind of cool to have that type of thing. I guess that's what There is a web authentication API. Oh, you're right.

But why so why don't we use that? Right. Why don't we use it and it it I I don't know. Is it any good? I don't know. Is it supported? Let's see. Browser compatibility.

It's not supported or not supported. Complaining about something we already have? Okay. Well, Well, okay. Well, maybe it's just us complaining then.

Yeah. I would be interested. Hey. If you're out there and you if you've used the web auth API, you know about it. Let's see. I wanna hear from you. I wanna learn all about this web of API. Is it any good? Is this something that we would actually like to use, or is it just one of those APIs that was made and it's Worse than the user land implementations.

Yeah. And also we should say sometimes these things are made to be low level primitives Exactly. It's not something you use directly and somebody is going to build like a login. Js or something like that and Make it much easier for your type of things. I tend to like a bit better when there is a nice API just built right into the browser. But I understand why sometimes they just build at lower level because Our tastes may change over time. And as long as there's low level primitives, the

Code on top of those can always change into different libraries. Yeah. And feel free to disagree with us on many of this stuff. A lot of these things are deeply personal.

So, Also, deeply personal is your website because you can host it wherever you want. And one of those places that you can host it could be on the, amazing developer platform,

Linode. Yes. Linode is the cloud computing that developers trust. They are Linux server hosting. They have pretty much products for everything under the sun.

And I'm going to talk to you today about their marketplace.

So if you want to be able to run apps on Linode, they have a whole bunch of marketplace that you can just install With a single click. They've got, KALI Linux, Joplin. Hey, did you remember we talked about Joplin a long time ago? Joplin's like an open source note taking app, where you can just like you can run a Joplin server and then you can use the Joplin apps.

And I always thought, like, I should try that out, but I was like, I don't feel like hosting it anywhere. Well, little did I know I can get the $100 from Linode in free credit and go ahead and just click and install and deploy a Joplin app.

What else do they have here? They have Node. Js, PyHole.

Have you have you put pie hole on anything before, Scott? No. You know, it does I mean, even routers that I have have a button, like, a one click block ad button. So I haven't had to. Oh,

that's cool. So Pie Hole is like a DNS level ad blocker, so you could you could run that on there.

Moodle, Magic Spam, Jet backup, Peppermint, you name it. Rid Oh, they have hundreds of different options on here, including MongoDB, Ruby on Rails, Django, WordPress, WooCommerce, you name it. So check it out. Linode.comforward

Syntax for $100 and free credit. Thanks, Linode, for sponsoring. Sick. Cool. Let's talk about some React stuff. This would be a good time for me to vent about React stuff.

Yeah.

Yeah. You know what? You know, nowadays, we're building websites on the server and for server and HTML, or a client side and server side. You know, it's something you gotta worry about at every single React project nowadays.

Using use isomorphic or use layout effect. So use layout effect, re Wait for the DOM to be ready before running the effect. But if you try to do this in any sort of server side context, React gets angry. It Hey. You can't do that. There is no DOM here. And then so you said, okay. Now we have useEffect and then use LayoutEffect, but we can't use LayoutEffect Many of the times that we want because it's almost completely worthless if you're not working in the DOM. So then you have to have this use isomorphic fetch, which Uses use useEffectorUseLayoutEffect based on the context in which you're in. And this is not something that's built into React, but it's something like, Honestly, you could save so much trouble by just having useEffect to be, use isomorphic Just being isomorphic by default. Like, I actually don't know what the implement or implications of that would be to say, like, alright. Now we have one use effect that's rid. Different for the DOM or that that is always waits for the DOM to be ready, and maybe you don't want that. So maybe you just have useEffect and use layout effect, But then they just make use lay it effect work on the server side behind the scenes. Because, honestly, like, that that's just just And overhead. That's something that anyone who who works in a React server side context is gonna hit that bug, and then they're gonna have to Google it. Then they're gonna have to change it. And instead, you could probably just ship it so that it checks to make sure you're on the you know, to make sure that the window is available before you're trying to do the thing. Next one we have here

rid is the dependency array in useEffect in React. So, the dependency array in React is if you are rid. Using any variables or data inside of useEffect, you have to pass it to the dependency array. You don't have to, but rid. You should pass it to the useEffect dependency array so that it knows which of the values to watch, so it can rerun.

Rid. And that that's always such a pain in the butt. And you get into these weird these weird use cases where, rid.

You had to pass everything in and then you pass in too much stuff and then just starts to get to be a big pain. And then you look at other things like rid And they have no concept of this at all.

And again, React is more explicit, and it intentionally does that. But rid. I much prefer it to just, like, figure out what you should be watching, and I don't want to have to to do that myself unless I want to rid. Watch a value that's not inside of there. Yeah. I'm pretty sure I'm looking

at dependency. Right? I don't know if views equivalent has a dependency array either, rid. Because I'm pretty sure it's just reacts. Either way, it it feels like a weird API.

It feels weird That you have to know that it feels weird that you have an array of things that you just have to kind of like have that overhead of knowing that that's what that array of things does at the end. But it's also weird that you have to have,