Fullstack TypeScript Apps with No Build Step?! with Brian LeRoux

Welcome Up to syntax day, we have Brian Larew on. We've had Brian on in the past once before to talk about, begin.com, talk about the old days of Phone gap. And today, we have Brian on to talk about, a couple things.

First, A very strong opinion he has about not running bundlers and just raw JavaScript right to the browser, JS well as enhanced dev, which is a framework for building web apps, which is like standards focused. Is that the The quick rundown or give us the the the pitch for what it JS? Yeah. I guess that foundation of it is,

server rendering, Web components.

Yeah.

GitHub a build step.

You can add a build step. If you wanna make things slower, it's fine.

Already getting spicy. I know. Yeah.

Yeah.

If you, if your code's getting spicy because maybe you bundled it and you don't actually know what you're shipping, maybe you'll want a, an error exception handling tracking service Because maybe you're shipping some bugs. So head on over to [email protected].

Use the coupon code tasty treat, all lowercase, all one word. You'll get 2 months for free, And, you'll be able to track and solve your bugs way better and faster. So yeah. Love it.

Gotta do that. Can't can't fix bugs you can't see. Can't fix bugs you can't see. That is a great

tagline. So I'm gonna I'm gonna start saying that, Brian. Yeah.

That's good.

So, we're both wearing our plaids today in addition to to being Canadian. This is our cultural identity, I think.

I I can't believe that we're we're both wearing

The red blood today just feels so right. There was a very high probability that this collision happened.

Yes. Like like, how many plaids do you own? I probably own, like, 15.

Yeah. I've got a good battery of flannels in there that I rotate through blue, green, red, And gray, it's the time of year. It's freezing out there. Yeah. You need to wear warm, cozy clothes. It's kind of like a

Holiday thing. You'd think they would be bigger in Denver than they are. I think we do we do more, like, furs, alpaca furs and stuff. Really? Like, we got alpaca farms ever. I don't personally, but I'm saying that's what you see. That and, Patagonia.

We just got Patagonia, but you don't see flannels everywhere. Yeah. I don't know. It's just It's a real Canadian thing for sure. Like, this this is, definitely a part of the Part of our heritage. Vibe. You know, this Arc'teryx, Bloodstones, You're ready to walk around in any Canadian city. The Canadian starter pack? Yes.

So let's let's talk about, Opinion on not using a bundler. So Brian is a really good follow on Twitter.

He's always spitting hot takes, but not obnoxious ones. There's a lot of people that spend all day on hot takes on Twitter, and I find it to be obnoxious. I feel like Brian has a really good, even head towards his opinions on Twitter. I'm always interested in, like, what does that you'll see me reply.

What does that mean? Tell me more. And one of your things you've been talking about lately is that you don't use a bundler.

You don't TypeScript it. You don't babble it. You don't run it through v. You just load JavaScript in the browser like some kind of psycho.

Tell us about that. Yeah. So I'm not anti anything to just be clear. I'm I'm pro Scott with the simplest thing that could possibly work.

And I feel we reach for a lot of tools without actually measuring or thinking about how we're We're gonna use those tools or what benefits they might provide. And so, you know, bundling JS a technique. It's it's not a edict.

And, Browsers are designed to execute JavaScript, and they're pretty good at it. And in past few years, they've gotten even better at it, especially networking. We've got, You know, h t p 2, h t p 3.

We can download things in parallel. We've got pretty good CDMs. They already brought gzip stuff for you.

And so I'm not I'm not saying don't bundle. I am saying you should measure, and you can't fix what you can't measure. And so you should use a tool like Sentry to look at what, like, you're building And understand what you're building to make that thing better.

And, yeah, start with the simplest thing that can work. And the simplest thing that could work is probably HTML, CSS, and JavaScript.

And, you know, if that isn't cutting it, then absolutely start, you know, doing what it takes to make things better. We we started asking in enhanced, like, how far can we go here and what can we build and, you know, we we heard a lot of people say, well, there's Certain types of apps that, you know, you just you can't build unless you use a bundler.

And we actually haven't found that edge yet. And, you know, we put our Put our work out there to for people to see. So it's it's all open source, and you can, you know, go to enhance .dev/ showcase, and you can open up Chrome dev tools, and you Trace stuff for yourself and see look at the source Node. View source even works.

And so, like, there there are downsides to bundlers. And and this is, You know, not my I don't have, like, a a hate or something. Like, people are like, you hate bundlers. Like, no. We we use Wes build ourselves At times, when we have, like, really chunky dependencies, but we'll we'll bundle those. We won't bundle everything.

Mhmm. So one downside is you gotta wait. Yeah. It's a it's a developer experience hit. Your iteration speed will always be faster without a bundle step.

You know, you can improve that bundle step by a 1000%. It's still slower than by a 100% than no bundle step. So avoiding a bundle step is Just better developer velocity to start.

Now the other cost and the bigger cost to me anyways is the debug loop is harder, and you can Band Aid that. So if you bundle everything, you've got 1 single file that's 1 column And you get a bug at runtime.

Chances are Sanity JS gonna help you figure out where that was, but chances aren't guaranteed that it will. Node we can use things like source maps to make that better and get, like, a real stack trace Wes we've got a line number and we know what to go fix. Mhmm. But odds are you're gonna chuck some darts with console dot log before you figure And that's slower developer speed. So you you again are hitting your iteration speed. And maintenance doesn't happen at a convenient time.

You're You're gonna be out picking up your kids or, you know, going over to your parents' house and have no computer or Like, the it's always at the worst possible time, and then your error is gonna be on, like, line 1, column 10,000.

Undefined is not a function.

You know, good luck with that, buddy. And and you're on the hook. And so, a real stack trace is actually quite nice, when you're debugging an application.

The other last thing to say about the the Node debug is it's Contextual.

So I feel, browsers, as we put more and more work on them, tool to have in your box, and and it's a useful one.

On the server, there's really no evidence that this is a good thing. So, we recently created a new project called AWS lite. It replaces the AWS SDK.

You can find it at AWS lite.org.

And we didn't wanna do this, at all. This was really this was really a thing that we kinda had to do. So Amazon, did the JavaScript thing, and they created a new SDK, and they based it on TypeScript, and they transpiled it. And it supports Deno Node and browsers. It supports common JS, DSM for all of those payloads, and they ship it in a single package to the resulting payload is something like 95 megabytes, which is a huge kick and land JS nuts for a cold start.

And worse, they're forcing that as an upgrade path In Node 20, you can't use the v two SDK anymore. And so we we're facing, like, a pretty big performance regression.

And they were like, well, don't worry. You can just bundle it.

Deno we're like, oh, man. That is not a great answer because now we can't debug it. And and node Errors are even harder to debug than browser errors because we don't have a dev tools for Node.

You know, at best, we're gonna have, like, a third party analytics or, error reporting service.

So you really want good line numbers in your node process, and that's a different place.

In AWS light, we have this Extensive set of benchmarks, and we show that we're about 5 times faster.

But the really most fascinating part about those benchmarks, you can go see and reproduce this Vercel. So this isn't you know, don't shoot the messenger here. I'm just sharing data.

This is science. Hopefully, we can all agree that that's a good idea.

Bundling slower than not bundling in this case. Now this is this case. This isn't all cases.

So you'll hear people say, well, bundling's faster.

And that's just not true. Like, there's different cases and not all bytes Yarn the same.

If you have a whole bunch of modules and you bundle them, certainly, you have less imports, but depends on what's in those modules. If you're loading a bunch of dead code Or you have a whole bunch of binary data in there. It could actually be slower. And in the case of the AWS SDK, it is. So Or in our AWS light, package, it is slower. So it always comes back to measure and Observe and improve based on data, and, and that's really what we're all about. And and when I'm Saying, you know, don't bundle. I'm not saying don't ever bundle. I'm saying don't start with a bundler.

Maybe grow into that need and improve you need it. Yeah. Yeah.

So one of my my long term dreams is to be able to Push the Node. I write to NPM as a package. You Node, like, wouldn't that be nice? Because that is such a pain in the butt To try to figure out why a library is broken because you go on GitHub and that might not be the same thing that's on Npm. And then you look into NPM, you're like, Which one of these 11 outputs am I using? And then finally you open it, and it's all, like, Variables are called a and h. And I just it's so it's so frustrating. And I just wish that there was I just want to import the code that was authored and and run it. And obviously, things make that impossible to do. Well, not not impossible, but much Trickier. So people are probably wondering right now, like, but what about x, y, and z? So we've got a couple what abouts here. And the first one is, What about TypeScript? Don't you use TypeScript? Yes. I love TypeScript. We do use it. We use it with JS doc and,

d dot ts files that we import.

So we even write TypeScript, and then we just import those as Scott comments. And Is it perfect? No. And is it as good as using raw TypeScript with all the tooling out there in the full ecosystem? Totally isn't. But it gets us types. It gets us that, you know, red squigglies in the auto completes. Yeah. And, that's what we're really here for. So, yeah, We use TypeScript. We like it. We use it with JS doc, which, you know, sometimes people look at me like I'm a lizard when I say that, but I'm like, it it works great, and it it's It's nice because there's no build stuff, and it doesn't obfuscate my code.

No. Because I and there's a like, a low key sometimes. There's, like, things that are Easier with the JS doc style typing. Like, you can type an entire function with an import rather than having to type Prescriptions. The result of the function and the yeah. Yeah. And I feel like things have gotten a little,

I don't wanna, like, make people feel bad. But, like, sometimes It feels like the type thing has gotten a little, out of hand.

Really generic.

Not very specific. The The guidance of the types is actually getting lost now and that they're becoming almost too too generic, too too fancy.

It's like, yeah. Okay. We got type guards here, but I don't know what this t value is.

Like, this is this is a meaningless value to me. Like When we hover over top of some of our Prisma types of errors, it's like like a 1,000 lines.

And I Some libraries are starting to go less in the generic area and more in the generated area because it's just like, I can't

I can't read this error. I mean, I I wanna know if something's a string or a number, and I wanna know, you know, what the name of that variable is and what Weird way Amazon decided to spell it this time. Mhmm. Yeah. From that, it's pretty diminishing returns for me personally. So Mhmm. Yeah. I I like the lighter touch Typing.

Like, I don't think it has to go so deep. It really it should be a convenience, and, and it should be somewhat Self documenting. So that's another nice thing about the JS doc. It comes in line and feels like, you know, now it's reading, like, what's going on? I don't have And I know this is why people wanna put it in 1 file because in you know, then it's all there. And that that totally makes sense at author time, But it it stops making sense at runtime for me. We'll talk about the JavaScript files. So one thing about shipping Wes straight to the browser

Is that you could have an entry point that could have it. It parses that and then you could have import inside of that. And then it approaches that, and that could be imported inside of that. And you get a waterfall.

So people are saying, yeah, HTTP 2, HTTP 3 fixes that. But then some people say, no, it doesn't fix that.

It doesn't. How do you No. JS that just something you live with? Is there's a potential waterfall of imports? Yeah. So,

you know, you're right in the code.

You you can you cannot do that.

Right? Like, if you're allowed to do

this.

There's a good part here. And and the good part I mean, honestly, in a lot of the time, we end up inlining the JavaScript, which sounds even crazier, I'm sure. So we'll inline it in the HTML document at the end of the page because there's so little of it, when you're doing progressive enhancement. Mhmm. We're we're talking Tens of kilobytes, not megabytes.

So when it's that small and you can view source on enhanced dev and take a look at how we do that. It's literally script tags, at the bottom of the page. Mhmm. And, it loads sub second.

Now if the if it was huge and it was big and we want to split it up a little and get smarter about sharing code between different pages, yeah, bring a bundle to the party. That's what those are designed for. But we don't have that problem to start with. So Okay. I'm not saying that problem doesn't exist. I'm just saying we can sidestep that by being sort of, Intentional about how we write our code.

And because, like, a lot of these frameworks are starting to say default everything to the server, The amount of JavaScript you need on the client is like I just I just went to enhance dash music.com, which is one of your your things, and Opened up the dev tools, clicked filter for Bos, and it is 21 lines including the, service worker registration.

So, like, it's it's not a lot of JavaScript. So does server rendering a lot of this just sidestep a lot of these Waterfall concerns? Yeah. And Wes, and, again, how you structure your modules and your and your components.

In The transpiler world, we start with JavaScript.

You Node, you you write oh, you don't really. You you write JSX or you write, you know, dot svelte or Scott astro or whatever. But, effectively, you're writing what becomes JavaScript files, and then you execute those JavaScript files to generate HTML.

In our world, you're writing either straight up HTML, which I know sounds totally nuts, or you're writing a JavaScript function that returns HTML and runs inside of Node. And so the only thing that hits the browser ever is HTML, And then, you know, some small pithy amount of client JavaScript for registering events and handling them.

And it it is a totally it's pushing all the JavaScript into the Node runtime, basically. I'm curious about how you still Sanity to do things like,

like, for instance, on this enhanced music page, right, you're able to have a player that sticks around amongst page navigation, and that's, like, typically thought of as, like, a spa feature. Wes.

How do you get around that those limitations?

It's an iframe.

It's an iPhone. Really? Yeah.

Using the platform. Yeah. IPhone in a web component of all things. It's,

like the most old and the most new tech

converging. Yeah. We so we had a snarky person say, well, you couldn't build, like, a Spotify with, like, web components.

And we were like, yeah. I don't know. Maybe.

And then we were like, oh, yeah. I was sure we can. No problem.

It misses on some aspects, I think, of the user interaction. If I was to redo this one, I'd probably actually just make it a single page, But not a single page app, but, like, actually just a single page. We got a long playlist and you just hit play. It would reload the page and reload the audio element with that player and Bob's your uncle because you don't really wanna pause and navigate music at the same time. I don't do that anyways. So I don't know. It it was a fun experiment, though. And we were like, does this iframe's been around a while. It should be Mhmm. Should work on mobile, and it turns out it does. So, yeah, it's a It's a weirdly valid technique now. I think it got vilified back in the table layout days and Yeah. Sort of left that one hanging, but, It's pretty stable now. The only issue I have with iframes might be, around rewriting client cookies. It's a bit funky, but, There are ways around that too. So, you know, there's always a hack with browsers.

And what about, like, Live reloading and and dev tooling. Like, you make a change, you wanna see it updated in in the browser. Do you still get that type of tooling when you when you go this way? Yeah. Well, in enhanced, we kick a WebSocket, and we watch your file system. And we will force a a reload of the client JavaScript

If you've enabled that and, yeah, this is another great thing about, the way that we're approaching things. The dev tools work, So you don't need a plug in or something like the the real dev like the Vue Sourcie inspect element dev tools. They all work, and they and they're great. Like, The only thing I find still really awkward, right now with Chrome DevTools, slotting with web components.

The The way they show it in the dev tool is kinda weird.

They, like, render these sub documents that you kinda gotta Dig into to find things.

It's hard to describe. It's almost like they tag them, and then they put them in a different place in the Dom than they really are. But, That's the only thing that I found kinda awkward. Otherwise, browsers are really good now, man. Like, Really, really good. Like, we are so spoiled. Node way it used to be was pretty rough compared to today. And, like and And it's hilarious because our ecosystems have basically niched us out of using the native tooling that's available to the platform that has been improving this whole time. So I feel there's a lot of merit to to getting back to some of these sort of really basic things and looking at, like, how the platform works and and using the tools that are bundled with your browser. Mhmm.

Even Wes kits tooling JS actually pretty great,

honestly. Yeah. Yeah. There are times when it it gets Annoying in the Wes kit land, but, I mean, they're shipping. And, see it. Last night, web kit announced

their, like, 17 release, and, like, I could hardly scroll to the bottom of that blog post. It was unbelievable. And Nicole Sullivan. Yeah. They just hired Nicole Sullivan.

So Oh, they did. Yeah. Oh, and she's a manager of layouts or something like that. Like, the Oh, man. I didn't Apple hired someone just to focus on Layout

rendering in the browser. Wow. Yeah. It's good news for the web. I love seeing that. It's awesome.

Yeah. Web kits, yeah, it's not it gets a rough wrap these days, but I I think they've been they've been giving it a college try for sure. Mhmm. It's It's been improving. And and the baseline like, our expectations now are are pretty awesome. Like, we're, you Node, oh, when are they gonna finally have view transitions Between or multipage transitions API. Like, we're asking for some pretty heavy duty stuff. Yeah. Yeah. Like, it's yeah. Like, the browser's pretty good these days. Remember Wes were stoked about rounded corners? Like Yeah. Y'all are spoiled.

Boxtado. Yeah. Stoked about that. Yeah. Boxtado. Oh, yeah.

Yeah. That was a thing. Yeah. Yeah.

Oh, that was good. Yeah. I I love just getting in there and kinda working close to the platform, but, you know, it isn't without its, It's, quirks and annoyances. We try and paper over that stuff inside of enhance as much as we can, but we're also trying to, like, See what, you know, what can we do with this platform that we compile to mostly.

And there's kind of a fallacy that we need the compiler. Like, I read this the other day in Twitter. Someone's like, know, it Wes really bundlers that moved up the state of the art forward. Like like, what? The bund you can only bundle to what the browser can do. Like, the bundler didn't bring anything new to the story. It just let us write more JavaScript and get away with it. It really doesn't change the baseline capability available to us. So

What about, like well, like, I think Babbel was such a major step forward because finally, we're able to Write our JavaScript in such a better way. And I know you didn't use any of the Wes 6 stuff until it was in the browser. Is that true? I think I remember that.

So yeah. Just wait. I was on board with the transpiling thing at the beginning.

Yeah. I just wait now. Do you not have ADHD? I we I I can't wait for shit. You don't want Sanity testing.

Oh, I definitely do. But, yeah. So Browsers didn't used to be evergreen, and I don't think they all were until roughly 2018. I I could be wrong about that. So there Wes there was a necessity for a babble. Like, we needed a babble if we wanted to use the latest stuff. There was no, upgrading your browser.

But now I visit my parents, you know, the holidays like everyone else, and I don't have to upgrade any browsers. It's Node done for me. And, like, that is a huge boon for web developers. So we we can We could kinda depend now on a baseline capability.

And, yeah, I'm not I'm not the best developer in the world. I don't need the most bleeding edge Features like I'm, you know, hiding devs and showing them like everybody else, and, that stuff doesn't really need a lot of heavyweight tooling at all. So

The browser upgrade path is so much faster these days. Like so last night, I was tweeting about how awesome Wes kit is, and People are like, oh, it's awful. Like, it's the new IE still.

And No. Like, people are like like, older older versions of of Safari. And I, like, I, like, went and looked at the stats, and I was like, Bos 17 came out two and a half months ago, and it Almost has a bigger market share than Ios 16, meaning the hardest browser to upgrade because you have to reboot your computer And, like, install your phone in the middle of middle of the night and, like, put in your code. That's, like, the hardest browser to update. And they already, in two and a half months, have Almost

eclipsed the previous version of the browser. I think that's pretty amazing. It's a way better situation than we used to be in. I remember being, Like, kind of suspicious of this too. I was like, I don't know. Should those browsers update? Like, could do something bad. But, no, that was the Absolutely right thing to happen.

I think the important thing to remember now is that we'd still need browser diversity and choice.

If we have a singular engine that's auto updating from a company that's effectively an ad network, that might not be, a great idea.

But that's that like, Safari JS important. WebKit JS really because as Firefox wanes, we we do need that competition to keep everybody honest and keep privacy in the the open web, at the forefront.

It's a one way door too. Like, we don't want that door to close. We saw what happened with IE. It was a bad scene.

Bad scene.

Yeah. Wes just had Eric Meyer on, and we were asking about the his idea about the futures of Firefox. And he also, You know, lamented that it it doesn't feel like it's going in a great direction right now in terms of longevity.

So

we need WebKit out there. I'll say this, though. Firefox has always been, like, on the door's desktop like, the The doorstep of death. Like, it always like, there's never been a moment where it's been like, oh, pnpm. Everyone's using Firefox. Like, it's always been this weird Scott of outlier, and yet they they seem to survive. So I don't I don't know how they keep pulling that. Like, they're like a cap. They have, like,

9 lives. Yeah. They keep coming back.

Yeah. I'm just waiting for them to pull out their AI Model that's fair or something like that, like, just like a Hail Mary. You know? I hope so. I'm a a long time Firefox user. I know we talk about lot on the podcast, but

I really, really hope they pull through. I keep a Firefox open. I have I have this is the like, I run all because, you know, there's even though we have auto upgrade and we have great standards, there's still always some feature that's weird on one of these browsers. It like, you can't even predict. You have to test it. So Yeah. I tend to switch my main driver, like, once every couple of, like, 2 months, especially now that with, like, One password or whatever, I can I can bop around pretty Sanity? But just to get a vibe,

see what's working there. Let's take some time to talk, about enhanced atenhance.dev, the HTML first full stack web framework, you have a really great little landing page here.

Do you maybe I know we we've already kind of touched on this a bit. Where do we wanna start here? Do we wanna talk high level? Because I feel like we've already done that a little bit, or do we wanna diving into some of these things. Yeah, I think let's let's talk about

what it is a little bit more. So is enhanced dev a meta framework, Meaning that you can build a full stack application ESLint side, server side,

run database queries with with that. I think it counts. The meta framework terminology is a bit weird because it you know, we had client side frameworks, and then they decided to go full stack. Use that loosely. I'm it's scare quoting right now. And so I I guess, a meta framework would be something that's, like, kind of, like, Client side capable, but also could do some back end y stuff. And, enhance actually went the other way. So it it started its LIFE has another project called architect.

And under the hood, it it actually is architect. It's a plug in to architect. Architect is a serverless framework For building apps using Lambda, API gateway, and DynamoDB.

And people would ask us, how do you do the front end for architect, and we'd be like, however you want. And they'd be like, no. Seriously, man. How do you do it? We'd be like, well, I would return HTML and progressively enhance it, and they'd look at me like I was a lizard. So I would eventually, we kinda had to have an answer. And, that answer for us became, enhanced.

We we didn't really wanna go down the road of being yet another React framework or yet another kind of meta framework that was, focused on transpiling. We felt there was a a need for somebody to be like, hey.

Why why don't we do this with web standards? Yeah. You Node, why why don't we try web components? Like, maybe they're okay Node. And, in our view, they are. So this could be seen as the meta framework for the web platform.

You know? Yeah. He's yeah. Yeah.

Cool. And I I think a big component of that is the, as you've mentioned, web components And SSR ing of web components, it seems like something that a lot of people are either I don't wanna say ignoring, maybe not Not putting up to a huge amount of importance, do what what are you guys doing to SSR web components, and and why did you you feel like that was an important step to take. Yeah. So initial work in HTML

is, just always gonna be faster. It's how browsers TypeScript tags load, a JavaScript. And so the more, work you can do on that server before you send it down to the client, the better.

Web components have kind of, been mostly a client side concern, and the web component upgrade is largely a client side thing. But, Christopher Joseph on our team realized, couple years ago Node, actually, that, you could expand the web component template independent of the behavior, and And so he wrote a little mini interpreter.

And so, enhanced literally takes web component definitions and expands them on the server and then returns the resulting TML. And most of that HTML JS in the light DOM by default. And I know what you're thinking right now. You're probably thinking it's an interpreter. Oh my god. It's probably pretty slow.

We, put server timing headers in recently, and we're rendering something like 10,000 components in sub 10 milliseconds.

So it's It's plenty fast.

It doesn't really need a build step to do that. You could shave 10 milliseconds if you needed to, but you probably And we still can do caching headers and stuff if we wanna, like, have, you know, a a static, result returned to the client. So, Yeah. It's a it's a little mini interpreter that opens up web components and then prerenders them. And then your client side code ends up just listening to events And, responding to them and then occasionally maybe doing some Dom manipulation, but in a lot of cases doesn't need to. And so, like, the the kind of, like, Key example I like to give. When you're building out an application, you've got a big header.

Chances are that's full of a bunch of anchor tags.

None none of that really needs to listen to JavaScript anymore. You can do all that with just plain old HTML and maybe some CSS for hiding and showing business.

And, that's a a beauty case for a server rendered web component. There's no listening on the client needed, at all.

And then the other thing is your header is not really something someone's gonna reuse on somebody else's website. It's gonna have your brand and your logo mark and all that. So You don't really need a shadow DOM or any of that isolation. Like, it's it's your website. So, you know, specific to your design system and your your application. So It's a nice, it's a nice default, and you can still drop into the client and do whatever you want.

I actually was just helping someone wrap Some React components and web components the other day to see if we could strangle them out.

And it turns out we can. And so, like, it's there's a migration path here too, for people that wanna kinda more low level or eke more performance out.

Yeah. That header example is very interesting because I'm working on some show notes for our episode on, React server components.

And one of the examples I'm trying to go through is like a header. Right? Like a header should be server rendered.

However, there might be parts of it that need to be dynamic, like a little notification bell that checks if you have any updates or something like that. That could that can be done in the the client. But the 1 question I don't have the answer to JS, what about just, like, underlining the current page? Right? You wanna show it like an active or an active parent.

Do you have to rerender the header on every single page then? Mhmm. Yeah. We do. Okay.

Yeah.

We allow for you to take over at the client level and, do things like change, you know, which, parent JS currently highlighted.

You get past the request when you render, and so you know the path, and so you can check against that to do the, you know, the underlying or the highlight or whatever. But, yeah, as you click around, the default experience would be fully server rendered for every Wes.

Yeah. There's a penalty to that. You know? Some of those requests you might wanna embed a single page app, but that's kind of the nice Thing about starting this way is that you have that flexibility.

Like, there's really a a single page app is a one way trip. You you can't really Come out of that and turn it into this multipage experience, but you can always embed, a rich application instead of a multipage experience.

Okay. And if I had, like, a Like a chat window inside my application that needed to update whenever there Wes new chats or something that, like, a part of the website that needed to be dynamic.

Is there something in enhanced that would let me, say, ping the ping the back end and refresh just that part of The application or was that a full page reload? No. Yeah. We support,

there's a better way. We support WebSockets.

And because you've got all of AWS, at your fingertips, you can use things like SNS or SQS for asynchronous events. So you could listen to the database, DynamoDB.

Mhmm. You could stream the response of a reader or write to that database to a WebSocket, and it could push the update into the client. The client doesn't even need to pull for it. And that could be an upgrade. That that doesn't even have to be, like, the default experience server under it.

The client JavaScript Kicks in, opens a WebSocket connection, and your progressive enhancement is listening for these events to upgrade the, experience.

And I I theoretically also could push HTML over that WebSocket as well. Yeah, man. HTML style. Alright. Yeah.

Yeah. I'm I'm into it. I'm feeling it. Like, it's weird, but,

it's it's a thing. Yeah. Yeah. Because, like, if you have a A pretty heavy dependency or a dependency that can't run-in the client but is needed to render that chat window.

It might make sense to just render that part on. And, like, that's

there's a lot that's big in the Ruby world, big in the PHP world. So It's kinda interesting. We're starting to see it now in JavaScript world. Yeah. We're doing a little bit of it, and, yeah, HTML over the wire is the same thing as JSON over the wire. It's just text. So Yeah. Node in our HTML works great with text. And, yeah, it's it feels strange.

Yeah. Feels like you're doing something you're not supposed to do, but it works perfectly fine and, is absolutely a valid tech. Yeah. The

jQuery load function, I'm pretty sure, if I remember correctly, a second argument to the jQuery load function was a selector, Meaning that you could load an entire HTML page, and then it would return to you a subset of the doms.

Let me let me select just this piece.

Yeah. Why not? You know? And and, like, I think, you know, whatever it is that gets the job done, It's valid. All these tools are available to us, and we can kinda count on the browsers being fairly good these days. So it's, It's neat watching the HTMX thing take their their whole thing is like, turning formally inert DOM elements into suddenly interactive DOM elements, but they'd You do it all declaratively, which I really, really love. And I I think there's more to be explored here around declarative, marking up attributes or using things like web components,

to add enhancements when the behavior JS available. Yeah. It's an interesting world. What what about, like, State management. I know that is, like, one of the biggest topics in React land.

Yeah. This Node, man, this one comes up a lot. So, We we tried to not have an opinion, and then we realized that's, like, basically telling people to go ask themselves. So we're we're just Forming opinions now.

So you can use a MobX or an x state or whatever if you want on the client. That's fine. Our our approach generally is get the thing working first with just HTML and then, you know, Intercept that on submit on the form and start doing your JavaScript magic as a second step because it's gonna be way easier than trying to decrypt how a State machine client side works to a back end.

You'll end up with just a thing that only works with JavaScript.

Mhmm. You'll end up with something that honestly a lot more complicated. So it seems more complicated to get the back end working, without client JavaScript at first, but it actually turns out that Most cases, you won't need state management at all.

We have a pattern on our blog where we get into how we would Theoretically show you how you could do it using a service worker.

And, you know, it it's pretty involved. We gotta take it off the main thread because we don't want to, involve, awaits, blocking the UI. So we put it in a worker, but we essentially listen for events, then we we use a thing called warp dom to update the dom based on, stuff coming back. But we will only do this after we get the form working first. And for a lot of forms, it doesn't matter. You Node? Like, if your form submits and reloads the page, you're you're just happy you got that person's email. Like, you don't care. Like and that person, I guarantee you, doesn't care.

So and browsers are pretty fast. Network's pretty fast. A lot of cases, we're talking subsecond responses. We're not talking 3, 4 second wait times here. So Most of the time, you don't need these tools, and I would say, try and build without them and reach for them only when things get so complex that you you have to have, like, a state machine on the client.

We're working on some better examples that sort of show what I'm talking about with, WebSockets because we think that's probably the end game here.

Usually, you're submitting some value to some either API or database, and then you wanna respond to the client with some result of that. And and that result might be errors. It might be it might be problems that they need to fix a form.

You spelled your name wrong or you used a character you can't use or You used a username that's not available because it's only available in the database.

That's a call that only the back end can make. And so, in these cases, you may wanna reach for, you know, slightly more complicated thing, but You really do wanna get that back end working with the client first, without any JavaScript, if you can, on the client. JS there any special sauce around

form submissions? So Wes built our recent website and Svelte, and we love the form actions.

And I see React JS starting to add that too. You just How do you do a form then? Do you just create like an one thing we didn't mention is you have file system based routing, right? So you just make a folder and you put a file in it, And that's your route. Yep.

So

you just make an API route? Yeah. We have a concept of API routes.

They follow the same symmetry as the page routes, And you can just put, like, a form in your page, and then you'll have, like, an API route, at whatever, path that you want, and then you would export a function that, named post to respond to a post.

And, Yep.

Bob's your uncle. That will either return a redirect or JSON depending on, if it was called with XHR fetch, XHR being, our good old friend, XML HTTP request, which nobody uses anymore, but I still say sometimes, and people look at me like I'm weird.

So if you use a an XHR or a fetch, we'll return a JSON payload. But if you, submit that form, just like regular HTML submit, it it'll do a redirect instead. And, the page will rerender with the state that it needs, and you don't need to do any Rejigging.

Mhmm.

Yeah. It's all that's kinda built in, But there's some work for you to do there. We we we have a thing we call the problems loop.

So so there's some, like, requirements for a good form.

A good form JS gonna give people good feedback. It's gonna give them good errors. It's ideally gonna give them good errors before they submit that form. So there's some client side JavaScript involved.

When you do submit that form, you better not lose the values that I entered that were good, especially if it's a long form. So if I have to, like, fill out my address the 2nd time you're gonna lose me as a customer.

And if you want this form to be bulletproof, you want it to work without JavaScript enabled.

And so in order to Achieve all of these things, you have to use a session.

And and this can get a little tricky. There's a bit of, like, hard to hard to parse ideas going on here. So when I submit the form, I wanna do the validation on the back end. I have to do it on the back end JS I can't, validate on the client and not have back end validation or else someone could, you know, break our security.

And when that validation finishes occurring, if there's a problem, I wanna return those in a session because we're gonna redirect, if that form is submitted without JavaScript, and I want those values to be populated.

Tools like Rails build this in and enhance. We have a set of opponents to build this ESLint. So this pattern is just there for you to to have.

And then at any time, you can, intercept that on submit and redo it yourself on the client.

I find once you've built out a few of these bulletproof forms, you you'll you'll get to that client step and you'll be like, well, I don't really wanna rebuild the whole thing. I just wanna, like, say, for example, do that username check before they submit or, maybe a password strength thing. You don't wanna submit a form if the password's like, you know, 1 character.

Mhmm.

And those are great use cases for progressive enhancement on the client.

And, yeah, you'll have a you'll have a forum that's Probably sub 5 kilobytes of client JavaScript, which

pretty good experience. Yeah. Right. Yeah.

Does enhance do anything for CSS, or does it just say, hey. You author your CSS as CSS, And we use web components for scoping. Is that is that the vibe? So we've got opinions.

One of our opinions is utility CSS is pretty good. And we think if you're gonna try and have this if you wanna avoid the ever growing, styles Scott CSS file, Then you wanna use something like utility CSS.

Utility CSS will fall apart.

Like, there are Specific components specific to your infrastructure or your application that are gonna need specific styles.

And in those cases, We'd recommend just embedding a style tag in the component and write raw dog that CSS, and it'll be scoped to that component.

And then we have a utility system.

People people get really divided about this. So you you can bring Sass. You can you can bring tailwind. You can you can write just raw CSS. Yeah. But we really, really, really think there are advantages to using a utility system and learning it.

Our utility systems, inspired by more tachyons than, Tailwind.

And, we we do a fluid type style, So it's responsive, which is to say you don't need a bunch of break points. It will scale up and down to mobile and, desktop Interfaces without having to rely too much on break points. You'll still need break points for some stuff, like Wes to hide and show that sidebar menu, for example. But, like, For the text in the page and most of the components in the page, I mean, flex and grid are are really, really good now. And, Node, Fluid scales and CSS variables. I mean, come on. We are spoiled.

So Yeah. So, yeah, we found, we don't need a lot Extra stuff there.

We bake in our our sort of opinions, and you can use them if you want to. But, we absolutely recognize that people have Their own opinions.

So they wanna do their own thing and, yeah, you can do whatever, basically. But we wanna get better at Playing this fluid stuff. I was I I feel it's it's actually pretty important, but, people aren't quite there yet. Yeah. I'm just rolling through all of, your CSS file on on begin.com, and you can kinda get an idea how it all works. Looks good. This does actually get back to measuring, though, and just to not to, like, belabor it, but I I think, the ever growing CSS problem still does even exist a little bit, in utility world where we've got build steps, and It it can be solved. You you can have, a file that doesn't get any bigger and support light mode and dark mode and multiple device Sizes and and fluid scales is is the path. But, it's another system, and it's a new thing to learn. So it's, you know, there's There's trade offs. Yeah. But, it it's worth measuring and looking at. And if you're finding that your your design system's getting unruly, I think, I think all paths point to components and, fluid scale. Yeah.

Yeah. There's there's 2 things for for us Before our CSS will finally get into a the happy land is the the contrast color function and the relative color Syntax, you give me those 2 things, and holy cow, our CSS files will get way smaller. So much. It was It's coming. A couple of problems right Node, and,

Yeah. It will solve all of those. Yeah. I love that. Woah. I'm gonna take a a deeper look at your CSS now. The the layout stuff is so good these days. One trick that we're still trying to figure out is do we want layout components? Like, remember back in the Flash days, you had, like, v Bos and h box and stuff like You know, a grid, you can get that kind of feeling, but there is a there is a bit of a barrier to entry there. And so we've been toying with the idea. Should there be layout components? Yeah. It did work well in Flex and is kind of a cool idea. Kind of do that on Syntax. On the new Syntax site, We went hard on grid for everything. So even vertically, the site's laid out with grid,

and name zones, Gutters and columns and everything, for just about everything within what our we're just They're just class based components, so it's just a class name. But, you could say that it's still a a layout component. Totally.

Yeah. I think it's great. Like, we're we're in a weird spot right now where the state of the art of the browser has actually Seated the state of the art of the practice. Yeah. Yeah. And we're still learning what is all the what are all these new tools meaning? And, like, yeah. They're coming fast Yarn. Like, Wes kit is dropping new stuff every week, it feels like, finally. And, yeah, there's all sorts of cool stuff in Chrome. Like, view transitions are barely

explored and offer, I think, like, a lot of functionality that we used to think was reserved for native apps. Yeah. I'm excited about that. That and, scroll driven animation's gonna be pretty we're gonna somebody on Twitter today was saying how they're so so happy that the, Parallax websites are dead, and I was like, buckle up. It's we're gonna have another run of that. Yeah.

Right after skeuomorphism comes back, fully, Oh, that will also get yeah. Parallaxes coming back. For it. Yep. Retro skeuomorphism.

It's weird. It does look retro, though.

Yeah. It's like, oh, wow. There was, like, stitching in that leather of the Oh, yeah. High cal. Oh, yeah.

I wanna ask you quickly about AWS re Invent. So that is Amazon's massive conference.

You went there. How was it? Why were you there?

I I well, I I go I've been going for a long time, and, I I go now as an AWS serverless hero, which is their sort of developer Sanity, embarrassing name for it, but awesome.

They they spoil us, and it's great. We Kinda get sort of priority seating and all the keynotes and can elbow our way into all the good parties, but it's It's overwhelming.

So there's between 6070000 people there. They book out the Venetian, the MGM, The Bellagio, I think 2 or 3 other hotels, but I can't remember which ones. I kinda don't leave the Venetian or the Wynn. That's the other one.

And, there are hundreds and hundreds of sessions a day. There are dozens and dozens of parties, every night. It is Almost overwhelming.

So for for me, I'm kind of in the the serverless y back Node Deno niche of Amazon. Amazon's huge. There's 400 services, And it spans everything from, you know, databases to machine learning to servers to whatever.

So the serverless world and the infrastructure JS code world is kinda the where my interests lie. And, Yeah. I try and catch 2 or 3 sessions a day. I did a couple talks and, otherwise, hung out with cool people and and watch the keynotes.

Saw Chris Williams there, which was awesome. I hadn't seen him in years, the old curator of JSConf. Yeah.

Yeah. He, he's doing good. It it was just a lot of fun.

Didn't catch COVID, unbelievably, with all those people. So get vaccinated and wear masks. It works.

Yeah. And it it was very Gen AI themed, which is a bit eye rolling, but also, where we're at right now as an industry. There's Clearly, a sea change happening. There's, a lot of undiscovered country there.

Amazon wants to own all the, You know, wheelbarrows and pickaxes for this new gold rush. And so there there are things called Bedrock.

It's It's kind of a sprawling service for managing,