Brad Gessler is an experienced Co-Founder with a demonstrated history of working in the information technology and services industry. He is also one of the authors of Fly.io. He talks about the "Phlex", its advantages, its impact, and how he uses it. 

 
On YouTube
Building Rails Application with Phlex - RUBY 595

Hey everybody, welcome back to another episode of the RubyRogues Podcast. I'm your host today, Valentino Stoll. We're joined by a very special guest today, Brad Gessler. Brad, do you want to introduce yourself? Tell us a little bit why you're famous.

 

Yeah, I've never thought about why I'm famous. So I'll shoot off the cuff here. Just my background with Rails, I was formerly the CTO of Pull Everywhere, wrote the first lines of code in a Rails application. And I spent about 12, maybe 13 years writing kind of the first lines of code for that, and then moving more into a management position, which I wanted to get back into coding, which is what I'm doing now. So right now I'm pretty much get to write articles about Ruby on Rails. Try a few of these ideas that I have, which you can read about on the fly.io slash Ruby dispatch. And just write about it and share it with the world and hopefully make Rails a better place.

 

That's awesome. You know, I haven't actually had a chance to play with fly.io yet. I have heard a lot of hype around it.

 

Yeah.

 

Did you see it before you joined fly.io or did you already know about it before you joined?

 

I kind of knew about it. I've known Kurt, he's the CEO of Fly for a while. And when I left, well, I had no anticipation of getting a job right away. But then Kurt said, hey, we're looking for a Ruby specialist, a real specialist. And at the time, I was also thinking, you know what, I'm getting tired of using Heroku. Things are just kind of old. Where's HTTP2? So I kind of got nerd sniped by Kurt into this. I can play with Rails and help build the future cloud for Rails, so I like to think about it. So that's what got my attention. And I'm like, okay, this seems like something that would be fun to do for a while. So now, again, I get to think about how could Rails be better and actually try those ideas, which we saw with some of the Docker work. My colleague Sam Ruby worked on that. So you can... generate a Docker file for Rails now, which should improve deployments for Rails apps dramatically. And more recently, I've been working on just component-driven view architecture. So it's been a lot of fun to be able to just ask myself questions like, hey, what if I just built a Rails application that did not use any herb templates, layouts, none of that. It was just built entirely of components. And I've got to like dive into the Rails source code and kind of see what's going on and. write about some interesting things.

 

Yeah, I have so many questions about this.

 

Heh.

 

I'm probably not alone. We talked off before the show about this. Rails out of the box user interface,

 

Yeah.

 

which I guess is purposely lacking. But it's still, there's nothing definitive for getting quickly started with a front end.

 

Yeah.

 

It's kind of like, OK. Here's a ton of other frameworks you can snap in place. And that's kind of been the new approach with all the front end tooling, right, with JS bundling and all that.

 

Yeah.

 

They all have great ways to get interfaces set up quickly. But there's nothing built in or native. And I kind of liked your article. I've been following along kind of your trek here on componentizing. these little interface components.

 

Yeah.

 

Because it is something you do every time. You get to this point in your application where you've done all the crud stuff, and you're trying to add some interaction. And well, do I install React at this point? Is that necessary? Can I use Hotwire? And at that point, well, how easy is it to start managing my interface elements systematically?

 

Yeah, yeah.

 

It's not there. Ha ha ha.

 

Yeah, it starts to get out of hand. It seems like your, like Rails does have some things out of the box. So you can generate scaffoldings. And some of the SAS starter kits have that too. There's like Bullet Train has super scaffolding. So there are some kind of point solutions out there that can solve those problems. But for the most part, What's really kind of driving my desire for this component driven architecture. Part of it is just more rapid prototyping. Um, but I also just want to move away from generating files to solve all these problems. Um, if you build your application entirely with all these generated files, then to your point, if you have to go and change something, you're just going through all these different files and finding this markup that you have to like change. So, you know, you need to get really good at regex. and just learn that and know how to search through all these files and grep and replace things. There may be a future where GPT-5 or whatever could just go in and figure it all out, which is kind of the wild card. But the thing that I'm focusing on now is how can we have something that's more declarative, where you could just say, hey, I want to render this form. I want all my forms in my application to look the same. Could I just drop a form component here, give it a model, and say, hey, I want to show these. fields. And there are some libraries that do that. Like I think simple form comes to mind, but the last time you use simple form, I remember editing the markup for what's emitted, it had to be done in a configuration file. So you have to like

 

Yeah,

 

shut down the

 

it's

 

Ruby

 

pretty

 

server.

 

painful.

 

Yeah, and reboot the whole stack. And what's interesting is I built, basically rebuilt the Rails form, help out from the ground up using flex. A lot of the work that I'm doing is based on flex, which we can get to in a moment. But I found in rewriting a lot of the Rails form helpers, there's a lot that's not, that's not going right in Rails form helpers that makes it kind of awkward to use. And there's, like, I can see some improvements, especially when it comes to like displaying errors and integrating with HTML5 client side validations. There's so much that can be done with the componentized architecture. towards building this stuff. And I think a lot of that comes from just, it's a lot easier whenever you're dealing with data inside of Ruby code, and they're just much closer together. And you don't have that whenever you're dealing with like partials and templates and all that. It's kind of like, okay, my view files are all the way over here in the views directory and my data and all this stuff is kind of jammed into these models and all these other things. Maybe the controller, but it's just kind of spread out and it's hard to reason through like the the state of a view and the data that a view has associated with it. So you do end up with all these crazy, um, kind of duct tape and bailing wire type situations. And we even see that with, with turbo like turbos pretty good. Um, but you're still essentially finding Dom IDs on a page and you're kind of patching based on that. Um, and I think a potential future I see with components is In Rails, we could have something that looks more like live view where you just worry less about kind of matching DOM ID with DOM ID and it just becomes more declarative and you kind of have these things that mostly just work and mostly stay in sync with the server. I haven't gotten that far yet where I'm like, okay, now it's time to wire turbo or hot wire into the components, but it's fully compatible. You can call out to all the the turbo helpers and all that stuff from components. So I don't see a reason why it can't be done. In fact, I know Joel Draper, he's the creator of Flex. He's been working with the creator of the Falcon server. I don't know why he can't remember his name offhand, but I think

 

I'll

 

they're

 

say

 

working

 

me Williams.

 

on a, that's it. Yeah, so they put together this proof of concept where the view can start rendering from the component. It puts this placeholder on the client side markup. while the async query is running. And then when the async query is complete, then it populates the rest of that view. So there's,

 

Live view.

 

yeah, similar. You know, we don't have, Rails doesn't have the beam runtime. So there's the question of how

 

Yeah.

 

do you manage that like the client side

 

I

 

state?

 

worry about that a lot.

 

Yeah, it might not be a big deal though. Maybe it is, maybe it isn't, but I haven't thought about it enough to know if it is. So yeah,

 

Yeah, that's fair.

 

it'll be interesting to see if it's possible. And it is, it's a question is like, what does that look like? It's probably built on Redis or something, right? Like that seems to be the solution for all Rails things. Like just let Redis handle it and then it's fine.

 

Yeah, I mean, the I guess the biggest issue is like that bidirectionality, right? Like you want, you know, it becomes like a, you know, you can only get past the HTTP handshake for so long before

 

Yeah.

 

it starts becoming a bottleneck, especially when you're doing a ton of requests. So I'm a little worried. So I know WebSock is supposed to like help in that regard to,

 

Yeah.

 

you know, make it go through a single pipeline at least, but I'm not convinced we're quite there yet.

 

Yeah.

 

But I'm curious what your experience has been so far with using Flex. My experience with component structure is kind of almost exclusively with view component

 

Yeah.

 

and partials, right?

 

Yeah, flex is kind of a funny journey for me because initially I saw it, I thought, oh, this is a terrible idea. Um, whenever I see something like that, or, or I have that thought, I think I followed up with like, okay, but there's probably something interesting going on here. Um, and so I'll just dive into it. Uh, and I think it's actually a lot like Tailwind where initially it seems like a terrible idea and to some, it still is like, it's, it's very, um, there's strong opinions about it. I think that's always gonna be true for Flex. There will be people who just prefer to write herb and HTML markdown, and that's totally fine. I get there's a lot of reasons why you would wanna do that, be it technical reasons or team reasons. But I will say that initially if you look at Flex and you think like, oh, this is weird, it seems like a terrible idea, if you start using it and kind of get past that initial level of discomfort, you'll start to like it a lot more, especially when you realize like, oh wow, I can take this view component and I can extract this thing into its own component and then put a method called like table or something or data grid within one of my views. And then it just kind of works. So you will get to a point if you use it enough where you're almost kind of building your own like higher level markup language. inside of these flex components. And that's whenever, at least for me, I realized like, wow, this is, there's something to this where you could just very rapidly build applications. And I think it would start off kind of slow where, oh, geez, you know, there's this initial, like, what are my, the components I need for my application? But once you kind of get past that initial setup of your components and you figure that out, that's where things just get a lot faster. And it's just very quick to put views together using Flex.

 

Yeah. That's pretty

 

Yeah,

 

cool. So, I

 

there's

 

mean...

 

still a lot of work in the docs that need to be done

 

Okay.

 

to lay that out in a much better way. I'm not even sure if what I said makes sense, but I think there's something to that journey of you're putting a bunch of components together. The next level is when you realize how you can move those things out and essentially build your own. DSL, I know that can be a dirty word, but not even in that way, I didn't even mean it that way. I mean, domain specific languages in Ruby are frowned upon sometimes, but the way that Flex does it and the way that it kind of evolves is just very nice.

 

Yeah, I know what you mean. There are so many gems that start with their domain-specific language, right? And they're like,

 

Yeah.

 

oh, look how great it is. And then you start having your edge cases and you're like, well, how do I get around these edge cases? And it's using their DSL, it becomes very hard to

 

Yeah.

 

extend

 

Yeah.

 

without modifying the internals, right?

 

Yeah.

 

So I was curious if you ran into a lot of that or if it was... pretty much all there and any

 

Oh, yeah.

 

edge case you could get around a different way.

 

Yeah, I like to say, if you're not running into leaky abstractions, you're probably in denial. Whenever I'm working on a framework, I do think that's very important. You need to build the thing with an understanding that there's abstractions leak. And you should always have an escape patch for whenever the end user, the developer, runs into that. So that's something that Flex does pretty well. For example. We all know that the title, we all know the title element in HTML documents. So there's a method inside of flex called title. If you call that it wants to generate a title tag. But if you wanna make a view component, say for a blog post, you might have title in there and you would call the title method. So you'd have this like conflicting namespace issue. But if you look inside of flex, you can call title tag. or you can register that element and kind of get around that. So there's plenty of escape hatches and flex, where if you run into some of these abstraction issues, you can always drop a level below that, get out of whatever trouble spot you're in, and then it's kind of off to the races. And I think this is true for all abstractions. When you hit those parts where they leak, it does take some time. You have to break your flow in working in your current level of abstraction and say, oh, OK, go the next level below that, figure out how to get out of whatever conflict or abstraction leak I'm in. And then once you figure that out, if you run into it again, then it's not a big deal. So there is a bit of a learning curve. And I think, again, that's true for any abstractions. But the question is, is that learning curve worth it? And can you be more productive using the abstractions? And again, when you run into trouble, how do you get out of that trouble? So that's all. there and flex and the stuff that I'm working on and the way that I work and solve these problems and release gems, I always, I think a lot about that. I'm running into the leaks, fixing the leaks and getting back on the saddle.

 

Yep. Yeah, I just think back to Slim, right?

 

Yeah.

 

Which, for those that don't know, is kind of like the slimmed down version of ERB.

 

Yeah.

 

And it tries to follow more along the lines of the DOM with just class structure, with minimized notation.

 

Yeah.

 

Which I know a lot of designers like and front end people. So

 

Yeah.

 

it definitely has stuck around quite a long time. So I'm wondering if you have had any experience working directly with front-end specific people, and

 

Yeah.

 

if you have, what their experience is working with Flex.

 

haven't yet.

 

Okay.

 

All I can go off of is reactions I've seen on Twitter, which like, you know, always take with a grain of salt. And I guess some

 

Right.

 

community posts, but it doesn't surprise me. I think it's similar to slim and Haml, which if people haven't heard of Haml, it's very similar to slim using a slightly different notation, but it's pretty much the same. People are just very opinionated about it. And I assume that's going to be true for components. So I've used Haml and Slim. I still use it to this day. I love abstractions on top of markup because if I don't have that, I'm gonna forget to close a tag and then I have to chase that down. So I look at these abstractions as these things are actually preventing me from shipping many bugs to production. That's how I look at it. But I totally get and understand how a front end designers who are familiar with working with HTML and CSS JavaScript directly, they're probably not going to like this as much, because it will feel a little bit different. And they'll probably run into some problems with assembling a paragraph in this thing. What if you have a paragraph with some text, and then you need to have some bold font in there, and you have to put a tag in there? But that said, I don't think it's necessary to just have all flex. I actually still think markup has. Um, areas where it is just better. Um, a lot of that I think is in content. Uh, like if you asked me to write kind of a, a semi formatted, um, essay or something, or some documentation, I wouldn't want to reach towards markdown. Um, assuming that kind of the notation there is enough for the problems that I'm, uh, trying to solve. But if that's not enough, if I need some fancier stuff in there, like, I don't know, embedded maps or. some crazier HTML, I would have no problem reaching for ERB or any of those templating languages. And you can actually still use that with Flex and render it from Flex. So if you build kind of the application side of your Rails app using Flex components, I think that's where it really shines. But if you're building more of a content site, I still think you can have Flex to manage the layout and some of the navigation and stuff, and it's gonna help a lot. But I would say like create your content in ERBR markdown or any of these other kind of markup languages. It just makes more sense where we have long form docs to do it that way. So I also think like a really good component front end for Rails is really important. And I also think a good kind of file-based content management system is just as important for Rails. And that's another project I've been working on is SitePress for several years, which is essentially, I was using middleman for a while, loved middleman, it was great. I tried to embed it into Rails because I needed that kind of level of content management in a Rails app. And of course, middleman wouldn't embed in there because it has a ton of gem dependencies. So I built SitePress, which is essentially a copy of middleman, except you can plug it into Rails. or you can run it standalone and compile a static website. But the nice thing about kind of components and middle or not middleman and site press coming together is it's very easy to create content. If you wanna add a blog or like support documentation, it's as easy as it was to create a webpage like 15 years ago in Dreamweaver. You just like create a support folder and start throwing documents in there, like upload that. Same idea, you're just like creating files. throw it in your Rails app. And you have like great documentation. And then for the kind of application side of the house, you should be using components. At least that's my opinion.

 

That's really cool. I like the idea. I think about even just like the whole Jekyll idea, where you're just like, okay, there is some initial setup

 

Yeah.

 

for the layout and whatnot. But if you take it outside of that, new content is just creating a file and uploading it, and then it just works.

 

Yeah. Yeah.

 

And I mean, there's a lot of static site generators now. in Rails,

 

Yeah, there's a ton.

 

I'm thinking Bridgetown.

 

Yeah.

 

You know, middleman was definitely one I was familiar with back in the day and it worked great, you know,

 

Yeah.

 

for what it did. I didn't honestly do too much with it. You

 

Yeah.

 

know, I didn't hit those limits like you mentioned earlier,

 

Yeah.

 

right, with a new tool. But, SitePress is pretty cool here. What got you into this?

 

It's my last company.

 

Well, before, hold on, hold

 

Yeah.

 

on. Before

 

Yeah.

 

we get there, because I had

 

Yeah.

 

questions about the componentized portion

 

Yeah, we can go back to that.

 

of your flex, right? Because

 

Yeah, yeah.

 

I think about like the ideal component view, it makes me think about design systems, right? Like

 

Yeah.

 

the, I'll never forget I saw this guy. Oh, man, I'm blanking on his name. But he was known for like He did the atom, if you've ever seen that. The atom project,

 

Yeah.

 

where all the elements were like tiny little pieces that built into your bigger mass, right?

 

Yeah.

 

And it kind of like turned into the design system

 

Yeah.

 

idea, right?

 

The atomic design system, right?

 

Yep, the atomic design

 

Yeah,

 

system. And

 

the name.

 

I forget his last name. I think it's Brad too.

 

I want to say it's the last name is Frost, but I don't know if I remember. Oh, Brad Frost. Yeah.

 

Fred Frost, yep.

 

Yeah. Yeah.

 

He has an actually a really great talk called Fuck the Bullshit, which

 

I'm out. Bye.

 

if you've ever been frustrated with anybody's user interface, like on any site, he just goes and through all the bad things people do and why you shouldn't

 

Yeah.

 

do it and why do we do it, right?

 

Yeah.

 

But anyway, I think about a design system as being like the... of where you want to head with an application for

 

Yeah.

 

front end, right? Because

 

Yeah.

 

having it all managed like that where everything is kind of normalized to compartmentalize pieces of whatever your application is doing,

 

Yeah.

 

that you can reuse these components everywhere. It makes so much sense.

 

Yeah.

 

And it allows the separation of designers and code, but also blends them, right?

 

Yeah.

 

There's so many great benefits of having that. And so I was excited about view components, right? Which is kind

 

Yeah.

 

of like, They, GitHub basically took all of their, oh, we have a design system and made this new thing so that they can make it easier to reuse those components into specific pieces

 

Yeah.

 

of code and design. And so it makes a lot of sense to me. And it makes me think too, you were mentioning Vue, right? Their component structure, I just really love.

 

Yeah.

 

I think it makes a lot of sense. And

 

Yeah.

 

of course I'm talking about Vue.js. And it just, the encapsulation of the front end is just like, it makes it so easy to reuse and it's straightforward and what

 

Yeah.

 

you need to change and alterate, right, the

 

Yeah.

 

properties of those specific things. And so Flex was very promising to me because it gave me that same kind of idea of, oh, like, okay, these reusable components that is in a Rails context, I could use Ruby everywhere.

 

Yeah.

 

You know. And not that view component isn't also like that, but it's blurs the lines a little bit more, right? Where it's like,

 

Yeah.

 

all right, well, you can also use HTML. Like you can still use all these other things, right?

 

Yeah.

 

Which I, you know, really it's pick your poison.

 

Yeah.

 

To be honest, there's not one better than the other.

 

Yeah.

 

But I think organizing and getting things into that design system mentality, I think is

 

Yeah.

 

probably the most important. And so I'm curious what your thoughts are on like, how Flex works on building that idea.

 

Yeah.

 

How easy is that to do? And like maybe other things that you've seen that maybe worked easier or better or maybe worked differently than you expected.

 

Yeah, so this is something that I also think about a lot with Flex and even ViewComponent. I think ViewComponent is a great library. I've used it in some projects. What's interesting about it compared to Flex though is in ViewComponent, slots are this kind of special thing that you have to think about. And with Flex, what's really interesting about Flex is a slot is just a block. That opens up a ton of possibilities. I won't try to articulate it because it's kind of hard to articulate it, but you can just make, it's easier to make certain things. Like for me to build, to rebuild the Rails form helper, it's just much easier if I don't have to think about slots versus markup. Like those are essentially the same thing, but in Flex, in Flex they are the same thing. It's just a block, it's just code. So you can mix the two and do some pretty interesting things. But aside from that, I think like with respect to design systems, what's really important is if you're building a component library, I think what's important there is that you can support a very iterative approach. And what I mean by that is it's one thing to ship a library, but you need to think about how our developers and designers going to work together to kind of evolve the design system. It's not going to happen at once. It's going to happen as a back and forth over time. And that interaction is important to think about. So when I put the view component kind of proof of concept together, one thing you'll notice is that I decided to support these inline controller views, which is kind of crazy. Who wants to put their view code inside of a controller? The reason for that, though, is whenever I start building a web application, I always think, I would love to just build it in Sinatra this time. It's just so easy to, it feels lightweight and all those kinds of things. But I've had enough experience with Sinatra apps where it feels great starting out, it feels very productive, but then I just end up rebuilding some version of Rails that is not as good as Rails. It's just

 

Oh,

 

kind

 

that

 

of

 

is

 

a

 

so

 

mess.

 

true.

 

Yeah, and it's, I mean, maybe it's not a mess for me, but if another developer comes in, they're just like, whoa, what's going on here? you know, where are my models? So I've learned the hard way that Rails like has its benefits there and that other people can come in and they kind of know where to look for things. So whenever I set out on this, I also thought, how can I bring that kind of initial prototyping experience that feels so good in Sinatra? How can I bring that into Rails? And that's what inspired me to support this idea of like, you can create a show class. nested inside of a, say, posts controller. And that's gonna map to the resources show route. And it's just going to like render that component. So you get that kind of benefit of, wow, I can just prototype the view inside of the controller and have that Sinatra like prototyping experience. And then when I'm kind of done with the prototype, I can move that view out of the controller and I can move it into the views folder or just wherever. It's just a class, so you can just kind of put it wherever. And I also think that

 

That's

 

kind

 

really

 

of,

 

cool.

 

I think that approach matters. I explain that in a way that matters to the developer, but I think that line of thinking for shipping a good component library is going to be important for, like how do designers engage with kind of this process? So I don't know, maybe if there's some designers listening to this and they have some ideas for what that looks like, get a hold of me. And I would like to hear more about that and understand just more about how that works to figure out what could be done for an eventual library that I will ship to make the life of designers easier. But all that I think is very important, not just what does this library do, what are its APIs, but how is it used over time? And is it... Can you ship something where people can evolve things? without having to boil the ocean all at once.

 

Yeah,

 

That's been my experience with

 

I

 

design

 

get that.

 

teams too. Like you can't design the design system all at once. You can, but you're gonna throw a lot of it away.

 

Yeah, I mean, from my personal experience, the biggest issues are getting shareability across applications.

 

Yeah.

 

Once you get big enough with your monolith, you start creating other apps just because it's better to have the encapsulation, and you don't even need the data in a lot of contexts in the same application. And so you do, you start shooting off all these other applications, but you still want the same look, right?

 

Yeah.

 

And so like, how do you get those same, you know, components like shared across those applications?

 

Yeah.

 

And then it becomes and it's weird because, you know, each of those has its own interaction, you know, potentially, so like, you kind of need to support JavaScript at that point. So like,

 

Yeah.

 

how do you blend the two

 

Yeah.

 

also and share it? It becomes very cumbersome to manage that on a big

 

Yeah.

 

scale. I think that's probably why no great solution exists

 

Yeah,

 

because of how hard it is.

 

I think there's two reasons for that. Flex solves one of those problems. The other is the asset pipeline. So I'll start with the first part. So since Flex is entirely Ruby code, it's way easier to package that up into a gem and ship that. You don't have to worry about creating a Rails engine. You don't have to worry about telling that engine, like here's where my template and view files are for this plugin. Even if you get past that though, you still, we see this in third party libraries, like it's not OmniAuth, what's the other one, Devise? Where you, if you wanna customize the login screen, you have to like type in this command. And again, it generates these view

 

Yeah.

 

files and it

 

Generates

 

throws them.

 

the new copy.

 

Yeah, and it just throws these view files in your project that look nothing at all, like what you want them to look like. So you have to like. essentially change those files and rewrite them. If you're lucky, you just

 

Yeah,

 

tweak

 

I

 

a

 

mean,

 

few things, but usually it's

 

even

 

a rewrite.

 

if you had like simple form, you used to have a plug-in where you could extend

 

Yeah.

 

it, right? Where it would, okay, it would at least generate in a, you know, your overall hierarchy of like how to generate a form, but

 

Yeah.

 

even still.

 

So my hope is that Flex is used to kind of ship a, we'll call it like a standard library of components. I think a lot of that would be calling into Rails helpers. The Rails form helper needs to be rewritten. I'm convinced of that. Not a huge rewrite and it would work the same. But the reason I think that's important is because I figured out a way where you can just create a form and a component. And then that form component will tell the controller which attributes to permit. So think about how many times you've built a Rails app and you forget to permit an attribute. You're testing it in the browser, like why won't this save? Oh, forgot to permit an attribute.

 

every time.

 

Yeah, so I think there is like forms are a problem that we all deal with. We all like we want kind of form errors to be handled, I think mostly in a. consistent way, but how they're displayed is that's where things vary. And I think flex can provide base classes for these things that are gonna be easy for people to just like add the base flex gem to your application. This like standard library components and then just extend it. And then you could probably actually use refinements in the way they're meant to be used and say like refine all of the form objects in my Rails application with this subclass that I extended from this thing. So when I write Whenever I render a form, I want it to use my subclass that's specialized for Rails. And in theory, you could do that and we'll just update all the forms in your applications without having to go through all these files and change a bunch of stuff. So that's kind of one thing I look forward to. All right, but to get to the second point, why is it so hard to ship JavaScript with a Rails plugin that you wanna write? And I wrote about this too on Ruby dispatch on fly.io. The asset pipeline is just, it's a mess. I think the official way now, the docs were recently cleaned up and it basically says, use import maps and use sprockets. That's kind of like the official way of going about it. But what frustrates me about that, I think it's, I like that we want to get there, but what happens whenever you need to bring in. a package, say from Node or from one of these gems, that's where things get really confusing. How are you importing these JavaScript things from plugins? It's not clear, the documentation isn't that great. And then there's a bunch of different kind of asset pipelines that Rails actually has. There's JS bundling, there's import maps. You can use web packer still if you want, even though that's officially deprecated. If you do start a Rails application with import maps and you need to use node for some reason, there's no great path to get there. There's no script that you run that say like upgrades from import maps to JS bundling. CSS is kind of similar. There's like, there's even more of those. I think there's DartSaaS, Tailwind. I think Webpacker can handle CSS2. And it's just not clear, like, okay, what do I use? So yeah, I wrote an article about that so I can understand it myself. And I think I left, I answered some questions, but I had some more questions, like why is the asset pipeline this crazy? And it's still that way. So I don't have a great answer for how JavaScript assets can be bundled in a clean way with Flux components. and then integrated with whatever pipeline, whatever asset pipeline the Rails application that needs to use it as running. I don't, like I hope the Rails community gets to a point where it's like, yes, this is the one way or maybe two ways of doing it. And makes that much clearer for people who build Rails plugins so that we can distribute JavaScript assets in a sane way. with Rails apps. I guess today you would have to like publish your JS package to Node or something if you're creating a Rails plugin. I don't really know. I try to just avoid distributing JavaScript with Rails plugins, which I think is kind of a shame.

 

You know, I remember, what was it, Rails Assets, right?

 

Yeah.

 

Where you used to have the gems that you could then include and it would bundle it with the node

 

Yeah.

 

pipeline, which was a little messy, but it worked.

 

Yeah.

 

It did work. And it plugged right in the asset

 

Yeah.

 

pipeline, right? Like it did solve some of the problems, maybe including way too much JavaScript upfront, right?

 

Yeah, I kind of now I find myself missing sprockets, even though at the time I knew I was running in all these problems using sprockets as the JavaScript pipeline, but it was, the thing it had going for it is everybody distributed Rails plugins that knew if they needed to serve up assets that it would be integrating with sprockets. So we kind of lost that. Now it's just, there's a bunch of different asset pipelines for different reasons. which actually is very on Railsy when I think about it. Rails is supposed to have this opinion. And at least for the past few years, there's been kind of this very lightweight opinion of like, let's use import maps, but there's just been so many other options where it's been kind of a mess. So

 

Yeah,

 

we'll

 

I mean,

 

see how that evolves.

 

I'm hopeful. I mean, it's been a year almost, right? Since

 

Yeah.

 

I kind of came out. And it's not really that much better, to be honest. It's

 

Yeah.

 

still a, which one do you use kind of thing.

 

Yeah, yeah, now there's prop

 

But

 

shaft.

 

you know, the

 

What

 

prop

 

do we do

 

shaft,

 

with prop shaft? Yeah,

 

right? Yeah, what is that?

 

yeah. It's supposed to replace sprockets, but like,

 

Right.

 

okay, should we use prop shaft for new projects? Maybe, maybe not. It's still unclear. And then it's like,

 

Yeah.

 

I want to distribute a plugin. Do I integrate with prop shaft? Do I distribute a node package or integrate with sprockets? So it's kind of, it's pretty bonkers. And it doesn't... I think it's harming kind of the plugin ecosystem around just like view type plugins. And like I said, going back to the two points, like I think flex will solve the problem of how do I distribute components in a sane way and rails in a way that can be like overridden and extended and all that stuff with kind of OO principles, but it doesn't solve the asset problem and it persists and it will until there's a strong opinion that says something like. you gotta use prop shaft and if you want to distribute a plugin like distribute it, distribute JavaScript over node or NPM. So yeah,

 

Yeah,

 

we'll see

 

I

 

where

 

mean,

 

that goes.

 

it's still that two, from a user interface perspective, right? Like front end wise, performance, like do you wanna wait for the entire page to render all the individual things

 

Yeah.

 

that you want to wait for the user to do, right? And say, okay, load the page as fast as possible and then just like let the user see stuff as loading, right?

 

Yeah.

 

Or do you want to just wait for the page to load with all the stuff already there?

 

Yeah.

 

And both go different directions as far as asset management.

 

Yeah.

 

And both have the problem of, are we including too much of the assets at once?

 

Yeah.

 

And then are we duplicating assets? And caching kind of resolves the duplicates, right?

 

Yeah.

 

Or could,

 

Yeah.

 

if caching were easy.

 

It's amazing how difficult it is to efficiently serve up assets. And

 

It's a

 

it's not just one discipline either. It's like you have to understand HTTP networking, all these factors to understand just how to serve up some JavaScript quickly.

 

So I'm curious, have you seen anything out there that seems promising as far as managing assets in this way?

 

Not really. I've had some like, I would describe them as like fantasies of, forget it. Let's just throw everything in a public directory and we'll deploy it to fly IO and just don't worry about fingerprinting and all that stuff. Just like get the assets closer to, um, users, which fly you can do that. You can type in fly deploy and it'll just deploy your application out to like 10 servers around the world. Um,

 

Oh, that's

 

but

 

cool.

 

it, it'd be cool to like do that. Just throw everything in public and, um, you know, maybe every request, it maybe has a short TTL and then it's checking e-tags every five minutes or something. Like, wow, wouldn't that, wouldn't that be so much easier to do it that way? Um, I haven't dove into that yet. Um, it almost seems like a joke, but that also tells me there's probably something to that.

 

Hahaha.

 

If you're shipping something that seems ironic, like fate loves irony. So. chase that down, you probably will have found something that people

 

Next time

 

are

 

we'll

 

like,

 

have you

 

whoa.

 

on and you'll have solved the asset problem for us.

 

Yeah, we'll see. We'll see. I think fly might solve it on that front, but I don't know. There's not really a great conceptual way of doing it without fingerprinting.

 

Yeah, you know that you make a good point about deployments and all these hosting providers hosting

 

Yeah.

 

all the same stuff. It's a little surprising that they haven't just been like, okay, we're going to host all the popular ones, right? We're already serving it, right? Why not

 

Yeah.

 

us cash it and save money?

 

Yeah, that's interesting. I didn't think of it that way. But yeah, why not, if you're running a major hosting provider, like, hey, use our node. I keep calling it node. Use our NPM CDN. And if you're hosting here, just tap into that, and it's all there next to your server.

 

Yeah, I mean, to be honest, I would use a hosting provider that did that.

 

Yeah, that's a pretty good idea.

 

Uh,

 

I think

 

but

 

there's

 

anyway.

 

third party ones that you're not paying money directly to them. You're like, how do they make money?

 

Right.

 

What if it's your own hosting provider? You'd be like, all right, if they start screwing with these assets, then I'm just going to leave. That'd

 

Yeah, that's true.

 

be interesting to combine the two. I'm sure Cloudflare does that. They run so much of the internet. They're probably kind of doing it behind the scenes.

 

Yeah, Cloudflare is pretty great.

 

Yeah.

 

I use them for some static stuff and zero problems.

 

Yeah.

 

Caching is so fast. So

 

Yeah.

 

back to the site press,

 

Yeah,

 

because

 

content.

 

I do want to touch on the content portion of it,

 

Yeah.

 

because I'm always moving my blog to

 

Yes,

 

different things.

 

yes.

 

It originally started as a Sinatra app.

 

Yeah.

 

And then I, you know, I got tired of updating tweaks to it when I wanted to add a new kind of content or media, you know, or something

 

Yeah.

 

like that. And I think I, I think I ended up on Ghost,

 

Yeah.

 

which is completely not Ruby. And I feel ashamed having it

 

It's

 

a little

 

fine.

 

bit.

 

It's alright to dabble in other languages.

 

You know, yeah, just try to try some out. But you know, the whole Hugo thing seems really interesting and

 

Yeah.

 

there's so many toolings built around that. And I mean, really I look at that and like, if you just have content,

 

Yeah.

 

why have anything dynamic generating it?

 

Yeah.

 

So what got you to wanna build your own? I'm curious

 

Yeah.

 

what that flip was with Middleman where you're like, all right, that's it.

 

Yeah, so I had two things kind of came together. Like I'd started playing with middleman for just kind of personal sites and small sites. I'm like, ah, this is great. This was, I don't know, five or so years ago. And then at Pull Everywhere, we kind of did what usually happens in Rails applications. You're like, oh, I have this big application I shipped. I need to have a landing page. And at that point, you're not ready to just you know, build a static site just for this one landing page. So you just kind of build it inside the Rails app, hook it up to the routes. You don't think much about it. And then, you know, a few months later, a few weeks later, you need another page. So you just kind of start collecting these pages up. Maybe you have a content controller. But it just, you start to end up with these pages that are kind of one-offs and they're scattered around the application. So that got annoying. And I'm like, all right, this seems crazy. I searched the internet, found high voltage. which is a Thoughtbot, lightweight content management system for Rails. And I'm like, okay, at least this gets everything so that it's in one controller and I can throw it in there and kind of have folders for it. And that I think is an important thing that the URL where you're loading the content maps to some folder somewhere. And that's a problem if you don't have that and you're just kind of winging content management in Rails. or using a database, you don't have that. So somebody coming in there is like, where does this content live? And you don't want to have them go on the search where you have to go through a router to find all that. It should just be like, oh, my legal slash privacy thing is in the legal slash privacy folder, all inside the content folder. So I thought that was important, which is that that's what high voltage did. But the thing that it was missing is middle, or not middle, man, it was missing front matter. and all these other goodies that Middleman had. So what is front matter? It's kind of, if you have a Markdown file, you can put a title. It's kind of like metadata. You put it at the top of the page and you, it's just YAML. They say at the top of the page where you say like, the title of this is privacy policy. And you can add just whatever kind of semi-structured content in there. And then whenever you render that, you can read that title from the Markdown. You can shove that into the HTML title tag. You could display it as an H1 in your template. So I wanted that. There's just some really nice benefits to treating your content as data so that you can do things like that. Or for a blog post, you may have a bunch of posts, and you have a publish at date. And you want to check that date to see if publish at is in the past. Then you want to show that. If it's in the future, you don't want to show that. So there's these kind of, I call them semi-static things. that you might want to check for before you serve up kind of static-ish content. So I wanted all of that inside of Rails. I tried to just throw middleman core inside of Rails, and it was not working. There was just way too many dependencies on all these libraries, like active support, older versions. It was just kind of a nightmare managing all those dependencies. And I think I tried Jekyll. Bridgetown didn't exist at the time, but the last time I looked a lot going on with dependencies as well, with just a ton of dependencies. So one goal for SitePress is like, how can I make just some really core, simple, lightweight content management functionality that would give me most of the features of middleman that I can embed in whatever? So like, I can embed it in Rails, I can embed it in a Rack app. And that was kind of the initial go at this thing. It actually wasn't built on top of Rails initially. I just kind of integrated it into Rails. So anyway, I integrated that into the website and it cleaned up a lot of the content where it was basically able to run middleman inside of a Rails app. And it just made content management so much easier. At that point, it was like, okay, this thing could be 1.0, it's running in production, it's serving up millions of page views. And it's actually working and it's solving kind of our organizational problems. And I started moving all of my personal websites and all these other websites over to it. But recently I've had this thought between components and content. To focus on content, when I think about if you are trying to ship a SaaS product and you spin up a Rails application, like the first thing you see is this Rails logo in the version, there's nothing, it doesn't even tell you what to do next. I find that frustrating, it's a missed opportunity. And the way that I think about whenever you boot a Rails application, you should probably see a content page. And there should be some instruction like, Hey, you should probably, you know, put the name of your product in there and then just start writing about it. Like that's the thing that you should ship first. Whenever you spin up a Rails application, it should be, here's this product. Here's what it does. Two or three features, like write that out and ship that before you even build any features, like ship that out there. Maybe have a. Give me your email address and we'll tell you when this thing launches. But in my mind, a good framework in the future, like a very productive framework out of the box, it should ship with that your landing page. Here's the concept, some supporting points will email you when it's ready. And then you don't really have to understand even how to write applications for that, you should just understand like, Oh, there's this markdown file in app content index. I can write about what this thing does and ship that. Um, and that ideally is shipped, uh, to a website, like in, in a few hours. And that's your first iteration. Uh, I think to like get, to get, to ship a Rails application very rapidly like that takes a lot more time. Uh, you have to think about, oh, it's a Rails application. Like I have to start building this application right away. It's like, no, you should probably write about it first and see if people even care about it. Um,

 

Right?

 

so I,

 

That's a

 

I

 

good

 

think,

 

point.

 

I see like a. A productive framework of the future should care more about content, even to the point where it'd be great if you could run a command that would just pull a privacy policy in terms of service that are kind of standard and reasonable and like dash as part of the thing that you ship. So, content I think is a huge opportunity to make a very productive framework of the future. like rapid prototyping abilities that I think about. Specifically with like how people should be doing it and how the iterations can happen.

 

Yeah, you know, I'm totally with you on that that new Rails page.

 

Yeah.

 

And I was I was kind of hopeful from all the latest improvements in the Rails new generator, where they have

 

Yeah.

 

their interactive now, where you can interactively select all the different pieces that you want to include

 

Nice.

 

in a new Rails application.

 

Yeah.

 

I was hopefully that would translate right into a view. So

 

Yeah.

 

like you land on the rails, you're like, what do you want to add anything here? Right. Like.

 

Yeah.

 

It could be a new page, but it could also be, you know, create a new model, right?

 

Yeah.

 

Like, you know, do some of the crud stuff. Okay, well, you know, I'm generating like, you know, I mean, honestly, it could be even like with GPT, right? Where

 

Yeah.

 

you say, okay, like, you know, give me a quick outline of what you're trying to build here and it would give you some ideas, you know,

 

Yeah.

 

potentially even run the generators for those things and get a scaffold, right? Like. It's definitely like this. It is. It's like, okay, now what? You know,

 

Yeah.

 

and I like on the new error pages where you see like, you know, run migrations now,

 

Yeah.

 

right? Where, okay,

 

Yeah.

 

like you got an error page. Oh, like you might want to run migrations. It seems like there's migrations pending, which why it wouldn't just run them if you're locally, I don't know.

 

Yeah.

 

But but you know, like little tweaks like that where, you know, it is missed real estate and kind of just like frustrating. to people that are just starting out too. Like,

 

Yeah.

 

okay, well, what do I do next? You know,

 

Yeah.

 

okay, like I have my new real site, but like, yeah, where do I go from here? You know,

 

Yeah.

 

and I like the idea of starting with content because that used to be the first thing I added to any site. Like you were mentioning high voltage.

 

Yeah.

 

That was my go-to. I just add it and then open up a markdown

 

Yeah.

 

and start writing something. And I would have it convert to. to whatever the template was.

 

Yeah, it'd be nice to have that dopamine hit that fast. It's like, oh, I

 

Right.

 

made the landing page and shipped

 

Right, done.

 

it. It should almost be so easy that you can impulsively do that after you impulsively buy a domain name. It's

 

Hahaha

 

like, oh, I had the domain. Maybe that's the default, right? It's like, enter your domain and then

 

Enter your

 

the

 

domain.

 

landing. Yeah. But the. It actually says domain for sale that I probably won't use. You just put the price of the thing and it's like, I have this great idea. I'm definitely going to do it. Um,

 

Right.

 

and you ship that. And then at least, you know, down the road, somebody like, Hey, I see your domains for sale. You haven't done anything with it for two years. Huh. But yeah, it would be great. Like just editing content, way more people can do that. So why not just, um, when you boot the thing, say like, Hey, go over here and write about. this thing and ship it. And then you have something that's public. So there's your endpoint. And then you can just hopefully rapidly iterate on the view component side of things to actually ship the application. And prototyping that should be as easy as I'll date myself here by saying it should be as easy as building a Microsoft Access application. Easier. You should

 

Oh,

 

just

 

that's

 

be able to

 

funny.

 

say, here's the form with these fields. This field's an association. It should just give me a dropdown. I shouldn't have to write all that out and give it an array. Just figure it out. And

 

Right.

 

yeah, there's so much that can be done in the view. It's ridiculous. So we'll see what happens with the view layer. We'll see how far that I get. Hopefully, just other people pick the stuff up and. I'm hoping somebody

 

You

 

figures

 

know I-

 

out Live View for Reflex.

 

Right. I mean, talking about prototyping, right, like that's definitely what Rails is great at,

 

Yeah.

 

and what I've loved about it. But it is like, it would be even better if you had like some kind of view component structure, where you could just drag and drop the all these shared resources and like build out your

 

Yeah.

 

forms or whatever that you're building. And then be like, all right, I want to hook this up to something, right? And then you could be able to configure or drag and drop things to connect them and have it automatically build models. I feel like all this

 

Yeah.

 

stuff is like, you're possible.

 

It is. Yeah.

 

And as a prototyping tool, I guess there's some sites already out there doing it, but it seems easy enough with all the tools we already have in Rails to be able to do that.

 

Yeah.

 

And I'm kind of surprised it hasn't surfaced yet, to be honest.

 

Yeah.

 

For it being such a, hey, this is a prototyping tool, like this is

 

Yeah.

 

the prototyping tool, you wanna build a SaaS product that's as successful as GitHub or Shopify,

 

Yeah.

 

right? Like this is it, you know? And

 

Yeah.

 

it doesn't, it can't do what we already know is possible.

 

Yeah, yeah, it's, I still run into people who swear Rails is the most productive framework. A lot of other frameworks have caught up. So there's also a conversation around like, oh, I don't know if new people are coming into Rails. And I wonder if those two things are related. I think it's more nuanced than that, but my mind wonders there. It's like, how could Rails just be made easier and more accessible so that kind of the next generation of companies and... and startups want to use it. So yeah, I think to your point, I do think there's a lot more that could be done around building the application inside the browser. And there's tiny, tiny hints of that. The run migration button is the first foray into modify things on your workstation project directory. I've thought about in SitePress, if I have a SitePress Pro product, it would probably be. some kind of web-based interface so that a non-technical marketing person could just edit the files and it would push it up to GitHub and trigger off a CI kind of process to deploy it. So yeah, I don't know, maybe that's an open source thing that Rails kind of kicks out. I do think that would probably go a longer way than improving documentation. There's so much stuff I see in documentation where I'm like, that should really be automated.

 

Yeah.

 

It would just save thousands, tens of thousands, hundreds of thousands of hours across humanity if these things were just simpler to do and had kind of a default answer. But yeah, there's a lot about Rails that it's just kind of left to the end user to figure out, where I think there could be stronger opinions that could kind of give it back that. being productive, competitively productive with other frameworks out there today. I do think Rails is a great web framework. Active record is great. The router is great. The controllers are great. The view layer could use just a lot of improvements. And asset management is a mess. Like if asset management had one answer and one opinion, and we can get to a world where we have kind of a standard library of view components. I think we see some really interesting things happening on the Rails front end. And then, yeah, I think for beginners, it'd be nice just to have more kind of tooling built into the Rails runtime and hit errors or whatever. There's signs of that happening.

 

Yeah. I mean, it would even be nice to have it on that landing page, like, hey, generate a new model with this command, right?

 

Yeah, yeah.

 

Or whatever would be scaffold, right?

 

I tried. I will say, I opened it. There's a PR.

 

Okay.

 

I opened the PR, I had that, and then I got shot down. I tried it.

 

What was the feedback for that?

 

Um, it's, I can't remember exactly. It was something like we can't DHH said something to the effect of we can't expect to teach like rails and the screen. That's not the intent. So I tried to counter that with, um, what we need in rails are better road signs. It's like, if you get in a car and you drive somewhere, you don't want to see a hundred signs all at once. I agree. That's a terrible experience.

 

Right.

 

But the, what I would say that rails can use more of is just like better road signs. Um, so whenever you do fire up that welcome screen, why not have it tell you what to do next? Like, Hey, go edit your routes file. Here's the path, um, generate a scaffold or something. Um, which I know I went with your routes files here, open that because there's a comment on the top of the routes file that says like, Hey, um, here's what you should do next. So I believe in having those road signs, little hints, um, in a way that doesn't overwhelm. You don't want to have like six signs or three signs or something like that. Ideally, it's just kind of sending people in one direction who are new and then people who have like used it over and over again, they just don't even pay attention to it anymore and it stays kind of out of the way. Really, like I had to rip that out. I don't know why. I know others have tried to improve the Rails home screen and it just, it doesn't work for whatever reason. Maybe it's a design masterpiece or something. I have no idea, but. There's a lot of room for improvement there as well. I even think that maybe we're getting to a point where Rails is just a mature web framework. And maybe our energy as an open source community could be spent kind of building a framework on top of Rails. And we see that in some SaaS starter kits, like, what's that, bullet

 

bullet

 

train?

 

train.

 

Yeah, and then what is the other one? Is it Go Rails?

 

Go rails,

 

Yeah,

 

or jumpstart rails.

 

that's it, Jumpstart Rails.

 

Yeah.

 

They're kind of looking at that. And I like to think that that's kind of the next generation of framework is like Rails is a solid web framework. They solve some kind of fundamental web problems. But if you wanna build kind of a CRUD application, there is a layer on top of that that could be helpful. And maybe that layer too would include more road signage and more of these tools that automate some of these things that are just so manual inside of Rails. So it'd be cool to see that and see a framework that's just highly, highly opinionated. I'm actually thinking of combining some of the things that I've talked about, both the content and the view components into this framework that I'm right now I'm thinking about just calling it monolith. So. I have used monolith to deploy monolith. So it's rubymonolith.com. I have like this landing page right now that's kind of out of date. But the idea there is like, all right, let's combine this world of component-driven development with content out of the box. And you type monolith new, you get all this stuff. And going back to kind of the different phases of... development that I talk about, the phase one, I think is like, oh, here's a landing page, like get that deployed. And then phase two would be prototyping. So you're just kind of essentially laying out the scaffolding, but not with a bunch of files. You're doing it with like inline view components and controllers. You get your prototype out there, get a couple of users, and then kind of the next phase after that is, you know, integrating stuff like Stripe to get payment, kind of getting things ready for production. I think it'd be pretty interesting to build kind of a framework around those three different ideas of component-driven development, content as a first-class citizen, and then instead of

 

Right?

 

throwing like 20 features on somebody who wants, like how can you break it out into phases where you can say, hey, for this framework, just focus about creating the landing page, explaining what it is that you're going to build. Once you do that, then prototype the thing and, you know, it opens up a new kind of level of plugins and documentation,

 

like

 

all

 

a

 

that

 

Rails

 

stuff.

 

Guides guide.

 

Yeah, kind of. It's like some road signage, some better road signage, if you will.

 

road signage.

 

Yeah. And I've thought, do you build on top of rails or not? And there's some good reasons to not build it on rails. Like if you want to build on more cutting edge stuff in Ruby, like rafters or threads, not threads, fibers. You probably don't want to build it in Rails yet, but Rails is such a giant and there's so much already built on it.

 

Yeah.

 

I think it makes sense to just start thinking of Rails as kind of this mature web framework and ask the question, what can we build on top of that? That kind of gives back that very, the highly opinionated thing that Rails, I think had more of back in the day when there were less opinions, it had like, one stronger opinion. I think that can be regained through a project like that. So we'll see. I know componentizing everything, especially in Ruby, is not gonna make everybody happy, but.

 

Enough

 

It can

 

with

 

work

 

the microservices

 

side by side.

 

already.

 

Yeah, yeah. I fell for spas, but not microservices.

 

Yeah, there's no escaping spas.

 

Yeah.

 

Anytime soon, anyway.

 

Yeah.

 

Okay, I mean, I like your idea. I mean, it definitely makes sense having, because you're right, Rails is a very mature framework, and at

 

to.

 

this point, making any changes to those fundamentals is gonna be harder and harder.

 

Yeah.

 

So another layer does make a lot of sense, right?

 

Yeah.

 

So yeah, it'll be interesting to see what comes from. I mean, I would love to read an article on that for sure. Ha

 

Yeah,

 

ha ha.

 

the hints are all there. Anything I write is kind of working up to this, assuming I can prove out some of these smaller concepts. But so far, it's promising. The view component stuff is 100% doable. Right now, I'm trying to figure out how to make batch resource manipulation easier using some controller hacks that I wrote about recently. So we'll see how far I get with that. I think that's another, in my mind, if you can solve batch resource manipulation, you've made a lot of other Rails SaaS companies happy. It's like, oh, I can just plug this into my Rails application and it works in a sane way. It's not a ton of hacks.

 

It reminds me that somebody posted recently on a Twitter thread about, what was it, Active Resource?

 

Oh yeah, it's like your OG. I remember that.

 

Yeah, I mean for those that don't know, there was this gem called active resource

 

Yeah.

 

that did a lot of what Brad was describing in some ways, right? Where it let you manage the entire crud portion of something

 

Yeah.

 

in a centralized location. And needless to say, it ended up causing a lot of problems

 

Yeah.

 

the longer you had to work with it.

 

Yeah. Yeah, I have many admin panels where they're still running ActiveResource.

 

They're still running.

 

Yeah, it's like, oh, I don't want to go in and clean that up.

 

Rude.

 

There's still a lot of, I want to get to that point where I have something that's like ActiveResource, but it needs to be composable. ViewComponent solves that. Another thing of boilerplate that I see constantly is like, loading data. I have a gem I'm working on. I actually don't know what the gem is yet. I just kind of push everything to it. It's called oxidizer. And a problem I solved in there recently was loading data. So I have this like at the top of a controller, you can just say, assign posts through blog from current user. And it kind of it assembles this nested hierarchy that makes sense from the point of a nested resource. It kind of forces resources to be one level deep. So I feel pretty good about that. Though there's some things I want to change about it so that it works better outside of active record and can work with classes. The thing I'm struggling with, though, is how can you deal with the update and the create methods in a controller in a way that's composable and not necessarily using inheritance from another controller? or like in the case of active resource that include, that just includes all the stuff that you find out about later when you don't want it there. So there's some interesting things there that apply to like, if you're loading a nested resource, a nested singular resource, there's certain things you, there's certain ways you want that to behave. If you're doing like batch resource manipulation, there's an entirely different way you want that to behave. But those behaviors are pretty common for whatever it is that you're trying to do. And I see that just over again in controllers implemented, which isn't terrible. There's something nice about seeing how the code is loaded. But I think we can do better. And I've been working on that. How can we load data in a sane way for most use cases? And then again, if the abstraction is leaky, like just drop back into your before actions. But I am trying to figure out how to make the update and save kind of flows that we see over and over again, like assigning the attributes, permitting them. How can all that boilerplate be abstracted away in a way where if it leaks, it's easy to drop down into that. I haven't figured that out yet. I've tried many times, but I end up in something that looks kind of like active resource. for admin panels. I have a few more ideas I'm going to try. We'll see what happens. Hopefully I can get there. I think between batch and a few other things I'm doing, maybe I'll figure it out. Maybe I won't. But I'll die trying.

 

I mean, I think that you make a good point how easy it is to experiment within Rails, right?

 

Yeah.

 

The framework is so mature now, it's pretty easy to find what you need, where it is, how it works.

 

Yeah.

 

And I guess adding more abstractions only hides it further, which

 

Yeah.

 

maybe is a bad idea, and I know that's the common argument, right?

 

Yeah.

 

But for prototyping, back to

 

Yeah.

 

our... the layer definitely makes a lot of sense, right? Cover it

 

Yeah.

 

up and do as quick as you can, move as quick as you can until you don't need to anymore.

 

And then when they don't work, they're easy to, to drop, drop down a level and fix the leak. But there's just so many things that have been shipped and I'm, I've shipped a lot of these that are, they seem great at the time. And then only later on you realize like, ah, that, that was the wrong choice.

 

I made a huge mistake.

 

Yeah. Yeah. It's going to, it's going to be hard to undo that. But yeah, there's, there's, uh, uh, abstractions are always trade-offs. Like I won't, I won't, I won't pretend that it's not, there's things to like about abstractions and there's, there's things to not, which is why, like it's a printable.

 

We need a new layer on top of that too for refactoring

 

Yeah.

 

and transitioning to a new

 

That's all going to be GPT. Like we don't have to worry about

 

Right,

 

that. GPT

 

that's true.

 

six is, I wonder about that sometimes.

 

It's all just gonna

 

Like,

 

be comments with prompts, you know.

 

yeah,

 

There.

 

yeah.

 

Ha ha ha.

 

I, I thought about that to the point where I realized that assuming that AI, I don't like calling it AI, let's get large language models, assuming that they're like on our side and helping us, they're going to want to write things that we want to read. So I have a hard time seeing a world where. We. humans want to read just code that's tangled up that we don't understand. So I'm optimistic that LLMs are going to be writing like code that's easy for us to look at and understand and hopefully refactor some things. Like if there's an abstraction that we need to go a little deeper, maybe you could explain it in a way where it makes sense, or maybe it could refactor that abstraction out. I could see it doing that. But I have a hard time seeing a world where we're just throwing spaghetti code into this thing, and somehow it all stitches it together and works. But we'll see, it's hard to predict what's going on there. There's days where I'm like, ah, GPT is so great at coding. I built some ZHS, no, ZSH extensions. I know nothing about shell scripting, and it did that. But then sometimes if I'm asking GPT some kind of, specific question, it'll pretend, it'll give me a confident answer, and I'm like,

 

Yeah.

 

ooh, that sounds believable and it doesn't work.

 

Which is kind of funny because you know the more specific you get the worse it gets.

 

Yeah, yeah.

 

Which is like you know it's a large language model for more generic

 

Yeah.

 

terms.

 

Yeah.

 

I guess right like.

 

I'm curious how the larger token sizes work. Because we have, I think, the public previews 8,000 tokens. I don't really know what that means. Like, what is a token? It's a word?

 

Kind of.

 

Yeah. And at the other end,

 

Sometimes they break it down where they have like every character is a token in

 

Yeah.

 

a word depending on it. It's

 

Yeah. You see

 

like,

 

the tokenizers.

 

it's not straightforward.

 

Yeah. And then the other thing I'd like to understand is, um, using a 32,000 token GPT-4 is that going from 8,000 to 32,000, is that a linear increase in ability or is it like an exponential increase? I don't know. I'm sure like people who are in the space, it's probably a really easy question for them to answer. Uh, but it'll be, it'll be interesting to see what happens as the the token size increases. It'd be cool to throw your whole GitHub repo in there and it understands it. And then you can just tell it to do things and it gives you some answers. And then I guess add to that the ability to like, um, operate a repel so it can try the stuff that it tells you to make sure the obvious stuff that it pretends to know that doesn't actually run works.

 

I wouldn't be surprised if Replet or one of these other

 

Hmm,

 

sites

 

yeah.

 

already has this.

 

Yeah.

 

I bet they do.

 

I'm sure GitHub's all over it. They're owned

 

Oh

 

by

 

yeah.

 

Microsoft. OpenA is opened by Microsoft. That was such a great acquisition by Microsoft. They just bought. They bought

 

Do you

 

their

 

think they

 

relevancy.

 

had any idea?

 

I think so.

 

Yeah?

 

Yeah. I think at the time before they bought GitHub, they had Visual Studio. I forget if VS Code was a thing, but it was just kind of. Microsoft wasn't perceived as, I don't wanna say they were irrelevant in open source, but they weren't at the center of it. And buying GitHub, it's like, hey, we're gonna be around for decades. And a lot of major projects are gonna be hosted on here. So I think that was, I think they knew what they're doing. I don't know to what degree of success they knew that would be, but. Yeah, for Microsoft, I think that was a great acquisition. I don't know what that means for open source, especially with open AI coming into the mix and seeing what's going on there. I know there's been controversy around, was it Copilot training itself on open source? And I've seen, I don't know if this is true or not, but proprietary code has been omitted from these models. I don't know how common that is or if that's even true, but... I think there's still some things to that. Like there's no doubt that these models are consuming things that are proprietary. Maybe it doesn't know it, but it consumes those things and spits them out. So it's, it's interesting. We're on the cusp of, of another kind of interesting, uh, push. Um, and it seems like there's gonna be some like real stuff coming out of this, it's going to be helpful. I'm mostly optimistic about it. Um,

 

I'm with you.

 

Yeah.

 

I see it as a great tool. And I mean, the more we can get past all of the, you know, is it ethical or is it stealing X or,

 

Yeah.

 

you know, if everybody's using it, does it matter?

 

Yeah.

 

It's almost like at this point, you know, the Mickey is about to be released, right, in copyright and like, So what, everybody's allowed to just make their own Mickey toys and sell them, right? Like,

 

Yeah, yeah.

 

you know,

 

We'll see

 

it's

 

Mid

 

almost

 

Journey.

 

like there's no rules. Yeah.

 

Yeah.

 

Mitch.

 

It'll, it'll just be cranking out Mickey Mouse.

 

Right.

 

Flicks. Like what Disney movie do you want to watch with Mickey Mouse? And it'll put the whole things together and voices and stuff.

 

Well,

 

Yeah,

 

we've

 

it's...

 

talked about a lot.

 

Yeah.

 

We should move to PIX here. It's been an awesome talk. It's been great to have you on, Brad.

 

Yeah.

 

Do you have anything you want to share? PIX is a segment. You just pick anything you're thinking about, working on, purchases, anything you want to share, really.

 

Yeah, jeez, purchases. We could talk more about Flex. Check Flex out. Get past the uncomfort it brings. That's kind of obvious, though. But flex.fun is the website for that. I'll go to something fun that if you live in an area where there's nice weather, you should have an outdoor desk. So in the winter, I'm like, I want a desk that's outside. So I bought one of those husky. desks from Home Depot that has like the little handle that you can put up and down. So you get that. That's kind of the obvious thing. Get a stool, buy a barbecue cover, because you're going to put it over that and then get a monitor arm and put a display on there and like cable the thing up, clamp it on there, hook your microphone and stuff up to it, and just have that thing outside. So when it's nice outside, you can sit out there and use your desk, stand up, sit down. When you're done with it, you just cover it. and wheel it off to the side. And it looks like a barbecue is hanging out there. But that's kind of fun. I have mine sitting kind of on the front patio. And whenever a delivery person comes by, they're kind of freaked out because there's just this person sitting over there in the corner in this desk. And I look like the receptionist or something. I'm like, can I help you? And I got my little keyboard there. What is this person doing? But yeah, check that out if you want to get outside. Put the desk together. And you'll enjoy that.

 

That's a great idea. I never thought about that. The barbecue

 

Yeah,

 

cover.

 

it works. It's rained for like four months. I live in Northern California, and I had the thing outside just under four months of rain, and it's dry. It worked fine. My, what is it, the USBC Thunderbolt cable, whatever corroded, but I solved that. You do want to make sure everything's waterproof. And Amazon's

 

Ha ha ha ha

 

your

 

ha.

 

friend there for all the little rubber fittings. Yeah, having an outdoor. Desk is a great thing.

 

Awesome. Uh, let's see. I'm trying to think about, uh, I have so many new toys. Yeah, I guess my latest addition to my office is, you know, maybe you can't see it from here, but it's this laser

 

Yeah.

 

engraver in the background.

 

Oh, nice. Yeah.

 

I was one of those suckers that saw Indiegogo campaign and was like, oh, I'm gonna, you know, this looks really cool. It's a 20 watt laser and it sits on my desk and it detaches so I can bring it around and carry it and like laser engrave the wall. And I'm just having like way too much fun with this thing.

 

Yeah,

 

but it's

 

that'd

 

by

 

be fun.

 

ComMaker. And yeah, I mean, the first day you get it and it has like, you know, you can engrave images even, and you just like sit it and put on your goggles and watch it etch into metal. And it's incredible.

 

Yeah,

 

It's way too much fun.

 

that'd be fun. Yeah, I have like too much stuff in the garage like that. No laser engraver, but it'd be fun to have that. Boom.

 

Yeah, we'll see. I mean, I've got a backlog of projects that I just like, I'm going to start

 

Yeah.

 

running through and it's going to be so much fun.

 

Yeah, that's awesome.

 

All right, well, it was great having you on, Brad.

 

Thanks for having me.

 

I'm looking forward to reading more of your content. Your fly articles are really fly.

 

Yeah.

 

You know, we make a lot of great points and you're tackling all the right problems, it seems. I hope that something fruitful comes from it and I'm gonna definitely try and use some of the ideas you got there for sure.

 

Yeah, yeah, no, it's, the content's definitely gonna, I'll be cranking a lot of that out and we'll see how far I get. But I don't know, hopefully I come out on the other side of this with a compelling framework that kind of makes Rails just that much more productive. But we'll see, a lot of interesting ideas there and I'm sure some won't work out, but hopefully some do.

 

Yeah, I mean, for all our case, I hope they do.

 

Yeah, yeah, we could use a better view layer and definitely better asset management.

 

Alright, well, until next time, folks. Valentino out.

 

See ya.