Episode 127 - Hype-Driven Development With Jared White  ## Metadata - Author: [[The Go Make Things Podcast]] - Full Title: Episode 127 - Hype-Driven Development With Jared White - Category: #podcasts - URL: https://share.snipd.com/episode/575439d0-c3bd-43b1-8cfb-ee7ea10fbcd5 ## Document Notes ## Highlights - **Ruby's Programmer Happiness Focus** - Ruby prioritizes programmer happiness and clear, expressive syntax over raw CPU efficiency. - This focus offers a unique developer experience that embraces clarity rather than low-level optimization. Transcript: Speaker 2 I know a couple of other folks were really passionate about it. Yeah. Speaker 1 So, Ruby kind of bills itself as being optimized for program or happiness. And that's very fuzzy. And maybe my happiness is not your happiness. So there's, you know, there's room for debate there. But I think the idea behind that is, if you're looking at two decisions with like language syntax or, you know, how to build a new library or how to do this or that in the language and the Ecosystem, if you have two choices and one optimizes for like pure efficiency, like in the CPU, right, like, here's speed, pure efficiency. But there's a lot more ceremony and like lower level access to all this different stuff. The programmer has to learn about and understand and keep all these mental models in their heads, right? Like that, that's one approach. And then the other approach is what's the, what's the clearest, most expressive, most almost English like syntax we can provide for this great DX and maybe the side effect of that is That it's not quite as efficient as it could be. ([Time 0:04:28](https://share.snipd.com/snip/ef8f9f32-9585-42fe-9642-909cb843cc12)) - **Good Developer Experience Matters** - Developer experience (DX) can sometimes lead developers toward bad web practices if tools encourage poor habits. - Good DX should steer developers to build idiomatic, performant, accessible web apps that embrace the platform’s strengths. Transcript: Speaker 1 Yeah, so. And I know that's definitely a this is definitely a big topic. And I think about it a lot. I think a lot about defaults and how tools can encourage folks towards good defaults or not so good defaults in my view. So, so I think it's important to parse this term developer experience. And so there's a couple different ways to look at it. You know, there's the, there's the thought that good developer experiences, eyes of developer should just be able to conjure up all the ideas of how I think something should work. And if this framework delivers those ideas to me, and I can use it, then great, like great developer experience. This makes sense to me, I can use it. The problem there is if, if those ideas as presented to you, and you, as you start using them, are in many ways, encouraging a number of bad habits for the actual platform you're writing On. So, you know, we're here to talk about the web. So I'm primarily considering the web here, but these issues can come up as well on, you know, native app platforms. And there's, there's this term that John Gruber came up with a while back for the Mac called Macast Mac apps. And it was sort of this thought that like, like, there are, there are applications that can run on the Mac. And then there are Mac apps, right? And you kind of know them, kind of, when you see them, you know them, like, they feel idiomatically Mac, and they have certain conventions and certain, certain UI, ways that they're Constructed and the ways they present things to use there that feel like, you know, like, oh, like Apple could have built this directly, but it's even better than that, right? Like, it's even better than Apple's own apps. This is a great Mac app. And I feel like there's, there's, there are certain key indicators of what makes a great web app. Like, this is a great web app. This is a great website. And what makes me sad is I feel like a lot of the popular frameworks and libraries that are in vogue because of DX don't produce good quality websites ([Time 0:07:54](https://share.snipd.com/snip/c32f5a81-03bc-47a8-b46d-ac367e5e3ca2)) - **Build With The Grain of Web** - Many popular tools work against the grain of the web, like treating CSS cascade as a problem rather than a feature. - Embracing the web’s unique behaviors leads to better, more maintainable web experiences. Transcript: Speaker 2 Yeah, I, I've heard other folks, and I've used the phrase myself before, like with the grain of the web versus against it. And it feels like a lot of a lot of the tools that certain developers get really excited about work against the grade of the web. So like, a good example would be, I sometimes see developers behind certain CSS frameworks or libraries complaining about the cascade as if that's a bug and not a feature of how CSS works. And they'll design these very complex tools to basically stop the problems of the cascade rather than learning how the cascade works and using it to your advantage because it could Be a very powerful, very powerful thing. So yeah, that's a really good, I think that's a really good explainer. I also, I really enjoyed your ([Time 0:10:36](https://share.snipd.com/snip/d013435a-725e-4c0b-8155-1f07a6bb5c78)) - **Web Development's Shifting Trends** - Jared recounted the shift from Rails with mostly vanilla front ends to SPAs with frameworks like React that break progressive enhancement principles. - The industry is now reversing course, reclaiming server-rendered HTML and progressive enhancement after over a decade of client-heavy apps. Transcript: Speaker 2 You had written a little while back about the great gas lighting of the JavaScript age. It was a piece that like I almost gave myself brain damage reading it because it was nodding along so vigorously. It's like, it's one of those articles, it's so good. I was angry at you for having written it instead of me. It just really, it just really described a lot of a lot of what I feel about how we build things now where kind of developers were sold this lie around these tools and what they do and don't Do for us. And it's just it's created a lot of really bad websites and web apps that are slower than they should be, buggier than they should be, break a lot more easily. Speaker 1 Yeah. Yeah, so for folks who haven't read that article, the gist of it was, and I intentionally used somewhat inflammatory language because I really want to get a certain point across. There's a certain point I was trying to get at which you kind of have to say, hey, folks, there's a thing here we need to talk about, get people's attention because I feel like this point Shouldn't be missed. And that is this. As I mentioned before, I really like Ruby and I've like building applications in Ruby and in the past, sort of the, well, I guess still, the top dog in the world of Ruby is the Ruby on Rails Framework. And back in the early to mid, well, in the late 2000s into the, like say, early 2010s, you know, a lot of folks are building a lot of cool stuff with Ruby on Rails. And the front end of that in many respects was pretty vanilla. I mean, it started using like prototype and some stuff a lot of folks haven't even heard of now, but then all of a sudden we're using jQuery. And I mean, we kind of had to at that time, right? Because browsers were crazy. And there's so many things he had to kind of work around. So jQuery was a way to sort of smooth over those rough edges. Speaker 2 All those Ivels clauses for different like features and methods. Right. Speaker 1 Like, how do you attach an event to a button? So, but there's sort of this sense that like, generally, we want to be like server rendering HTML and delivering that to the browser. And generally, we want to present forms to the browser. And when you submit the forms, they send form data to the server and it can process that form data. And Rails kind of helped pioneer ideas like rest of like, here's how you use URLs properly. And here's how you build out your controllers and your views. And so there's sort of this mindset of like, here's how you build web apps. And it wasn't perfect. And there were weird edge cases and you could get into spaghetti code and all that stuff. Sure. But I think the basic gist of it was like, the Rails framework was helping you build with the grain of the web and not against it, as we were saying before. But then, almost on a dime, I feel like the industry was kind of pivoting rapidly to angular JS. And then after that was react. And you know, we've had some other things come along too. But like, and all of a sudden it's like, no, we're, we're building front ends that are distinct from backends and we're sending data over the wire using JSON APIs and bringing JSON back And updating state on the client and rerendering HTML from the client and all this different stuff, right? And you'd like go to website and if your JavaScript wasn't working perfectly, you'd see blank, just blank. And a lot of folks in my community using Rails and other tools like that, we're saying like, hey, hold on, hold on, folks, whoa, there. Time out. What happened to progressive enhancement? What happened to accessibility? What happened to like performance on slower devices? And like, what happens if you get a JavaScript error all of a sudden your forms just aren't submitting anymore? Like, what happened to all this stuff, right? Like, we have this whole set of like best practices and like, here's how you dot your eyes and cross your T's to build a good web app and be a good citizen on the web. And ([Time 0:11:29](https://share.snipd.com/snip/16ece00b-48de-49e2-9cae-203eb6c4e48e)) - **Astro Combines Flexibility and Efficiency** - Astro's island architecture allows mixing frameworks on a page and shipping zero JavaScript by default. - This keeps flexibility while reducing vendor lock-in seen in single-framework apps, appealing as a modern web development approach. Transcript: Speaker 2 Is that a good thing? A bad thing? Is that, I think one of the things I wrestle with is, is that kind of the future of, was that the next big trend in web development? Or is this just kind of some little stop gap that's gets us to whatever thing is next? I think about, do you remember the transition from jQuery to React? There was this weird in between thing where people were building all these like micro versions of jQuery, like umbrella JS and stuff to kind of like, bridge the gap. So like, I can't tell if these tools are just like getting us from where we are to what's next, or if they are what's next? Speaker 1 Yeah, it certainly feels like there are some, some areas where there's parallel evolution and kind of convergence on some new paradigms, which, you know, in many respects, takes some Of the good things of the quote unquote old way of doing it, but modernize it and, and make it make it good once more. So that's exciting. I don't have a lot of experience specifically with S felt. There, but one, one thing that does bother me a bit right out the gate with that, and you know, using S felt kids, a framework for example, is you're locking yourself into one single view Library and set of conventions, right? Like, if you adopt S felt kit and build a website with it, you're stuck with S felt. Like, if you suddenly need to use view or even react or something else on some particular page, like, how do you even do that? Whereas a quote unquote meta framework, like, Astro definitely intrigues me because, you know, out of the box, Astro does provide its own component model, but it's purely like static Or server side, if you will, right? It's just a way of like defining essentially an HTML template that can take some data and render out some HTML. And there you go. So it's, it's really just like a nicely evolved, you know, take on partials, HTML templates, whatever. So you can use Astro and ship zero JS to the client, and you're fine, right? That's its claim to fame. But then you can sort of define like, well, I want an island here. It's this island's architecture idea of like, on this page, I need an island. And in this island, I need a react based form to do a bunch of react stuff for a form. Okay, cool. Like, if you never go that page, you never need to load react. This is great, right? Like only going to that page and and hydrating that react form, if you will, suddenly you have, you know, the features of that world, same for view, same for other things, even like LIT, Which is a library for helping you build web components, you could just load LIT into an island on a certain page and so forth. You can also use these different technologies purely to render stuff statically as well. Like, if you say, well, I like react for building X, Y, and Z for whatever reason, you could use that to statically render some HTML. And it doesn't actually need to load react on the client. So Astro gives you all these sort of hooks into all these different tools, and you can decide as the developer, you know, how you might want to use those. And I think as a ([Time 0:18:10](https://share.snipd.com/snip/9e3779d6-85c9-431f-b490-1102a18fe7ca)) - **Embrace Small, Focused Libraries** - Favor small, specialized libraries that do one thing well to compose your web apps instead of large all-in-one frameworks. - This approach aligns with the Unix philosophy and maximizes flexibility and long-term maintainability. Transcript: Speaker 2 Are we in kind of the, I guess, the life of the modern web? Speaker 1 Well, Chris, I was listening to the vanilla JS podcast the other day. Speaker 2 That guy's a jerk. I can't don't listen to him. Speaker 1 No, it was very fascinating because no joke here, because you were talking about, you know, using template literals to sort of maybe render a chunk of HTML from JavaScript, if you need To do that sort of thing versus something like JSX. But currently, there's not sort of a pervasive browser API for sanitizing incoming data, nor the insertination, like that. And that's the kind of stuff that really interests me about building for the web. And that is like, like, increasingly, we do have browser APIs like that. Increasingly, we do have like an API to do this one thing and another API API to do this other one thing. And I wish we had like user land, you know, dependency packages that were also like that for the front end, right? Like, I'm, and sure, there are things like that out there. But I feel like, you know, a lot of folks, instead of thinking, like, well, I need to sanitize my incoming data before I stick it into my HTML. So I'll use this very tiny little library that does that one thing very well. ([Time 0:29:43](https://share.snipd.com/snip/1cee97c0-5e0e-4cd9-acc2-d59a15376efe)) - **Use Turbo for SPA-like Features** - Use Turbo to enhance vanilla HTML apps with SPA-like navigation without full client-side frameworks. - Turbo streams allow partial page updates with minimal JavaScript, preserving performance and simplicity. Transcript: Speaker 1 Folks learn some of this stuff. And then in terms of particular libraries, I'm super enthusiastic about it. I'll throw a couple out there. One is actually mentioned earlier, hot wire turbo. I think turbo is a pretty fantastic library. It's it's not perfect. But the thing I really like about turbo is like you can take your totally vanilla HTML, whether that's server rendered or statically generated, and you can take totally vanilla forms, Etc. And just by sticking turbo on the page, it suddenly feels a lot like an SPA in terms of like, you know, if you submit the form, the entire page doesn't just like blow away and an entire new Page load, it just kind of just swaps out the HTML needs to. And you can, you know, have that be for the for like everything on the page kind of by default, or you can get more targeted of like, when I submit this thing, it just send me back a little Fragment of HTML, and I can just direct where that gets updated on the page. And there's other libraries that do this to like HTML, and unpalley, and there's like a few out there that do this kind of stuff, which can be interesting to check out. But I'm personally familiar with turbo and really like how that works. And and turbo streams also is a pretty cool idea too. And the way that works is, they have just like a few little what are essentially custom elements, like literal turbo stream elements that are just kind of like directives, right? It's like, for an element that has an idea of who here's some HTML with bar in it, update foo, right? And by and by sending those sort of commands or directives, or I guess they call them actions by saying those actions over the wire as HTML, you can use like any back end you want, right? Like any back end you could possibly imagine could just generate a few turbo stream actions and send them over, and then parts of your page update, right? And it feels magical. It feels like, wait, I don't need a whole SPA client side framework components, all this stuff to do something like that. I can just use this one little library in HTML. So that's a go to for me for ([Time 0:38:42](https://share.snipd.com/snip/d3181c19-3e4b-4a08-a36d-f787ed937e6a)) - **Adopt Shoelace Web Components Library** - Shoelace offers customizable web components that work everywhere without a heavy framework. - Import individual components on demand to enhance your app with modern UI elements easily and flexibly. Transcript: Speaker 1 Of turbo. And then the other library I really like is a component library called shoelace. And shoelace uses web components under the hood, but you don't really need to know most of those, you know, details, you can just literally say, I just I just need like a nice looking button, I'll import a button. And it uses a button tag under the hood, but you just write like SL dash button for shoelace button. And you can just use that on your page. And it comes with cards and dialogues and all these different things. And you can kind of use it out of the box, it looks pretty good as is, but you can also customize a lot of stuff with some CSS variables or with like what they're called shadow parts, which Not a lot of folks know about, but just real quick, because they use the shadow dumb under the hood inside the web components that exposes like parts of the component as literally parts That you can style with CSS, which makes it pretty flexible. And yeah, I'll reach for shoelace a lot on different projects when it's just like, I just need like a color picker. And I know like, again, browsers themselves know for like native color pickers. But if you need one that's, you know, more fancy, and you can like define preset colors to choose from and all this different stuff, like you can just pop a shoelace color picker in an app. And that's it. Like you don't need any other library, you don't need to be using react or view or whatever, like it literally can work anywhere. And I know this to be true, because I worked on a project a while back, that was like an old rails app like built a long, long time ago. And you know, the view layers like pretty crafty and gnarly these days, even for a rails app. But they need a really nice way to pick some colors for a template that folks can like edit on the site. And it's just like, okay, shoelace color picker, boom. And it worked. And the colors submit with the rest of the form. And you're done. So shoelace is really cool. Speaker 2 Yeah, this looks a lot ([Time 0:41:08](https://share.snipd.com/snip/9c9b16a2-c37a-48f1-a66b-abfbe88de5f4))