2024 Reboot: What's Going on Lately with the Headway Development Team

Jon: Hey everybody. Welcome to Even Keeled. I'm your host, John Kinney and today we're going to be doing a new format going forward to bring you the latest and greatest from the week at Headway, to talk about some technology trends and things that have happened in client projects that we've learned from, as well as things that we anticipate needing to be a part of our workflows going forward.

So today I'm joined by Dan Deamer, mobile lead at Headway. Say hi, Dan. Hey everybody, we've got Tim Greenmore, a development lead at Headway as well. Hello everyone. And Chris Hell, the development lead at Hedway. So there's a theme. Say hi, Chris. Hello. Alright, so dev leadership team here joining you to talk a little bit about some topics that have been sloshing around our Slack rooms for the last couple of weeks.

we've got a few things that we're going to walkthrough highlight, but, uh, expect a little bit more of a fluid conversation. Talking with, one another about these topics can lead us into some other areas. We don't have to stick to the script. So hopefully you'll enjoy hearing some of the things that we think are interesting in the world of consulting with our core technologies, Ruby on Rails, Elixir and Phoenix, React Native and React for the web.

And we'll go from there. So, we don't have any live callers. If you want to reach out to us and ask questions of us, there'll be ways to do that. but. For the time being, we'll just be chatting with you as if you're a part of our panel and you're in the audience. So, let's start with something I did recently this week.

I submitted a talk to RailsConf. So I've been going to RailsConf on and off over the years. Uh, had a very memorable experience on the light rail in Portland. Going back to my hotel room, almost got accosted by a gentleman, but luckily made it safely. Uh, always enjoy getting out to the communities and, uh, hearing from other folks in the Rails scene.

Um, and haven't had a chance yet myself to speak at a RailsConf. I haven't really been submitting talks too much, but recently have been trying to get, on that, level of being able to speak in front of colleagues at RailsConf. So I submitted a talk. around the concept of creating a development environment in Terminal Vim, with NeoVim, that would allow you to, bring a really solid experience to your everyday work building Rails apps.

And a lot of folks have moved to VS Code, and there's Been new interest, I think, in what Vim can match from a VS Code perspective with NeoVim. And so, I'm hoping to be able to bring that as a two hour workshop to the audience, if there are people that are interested in learning how to develop in Rails.

So, uh, we'll see if that gets picked up, but it'd be exciting. I think Tim, you might be able to help, on that front as well as a co presenter, co workshop author, right? Yeah, yeah, absolutely.

Tim: I mean, love them. It's been fun being able to evolve with development languages and frameworks and.

Techniques and be able to remain in the same editor for many years and see that not only has it kept up, but it's really evolved and continues to be the quickest way,

Jon: at least for me

Tim: to program across tech and across client work that we get.

Jon: Yeah, one

Dan: thing I noticed, let's talk you back from from using some of the newer things.

Like, why have you stuck with them?

Jon: I'll, I still have VS Code installed, right? And so, and over the years, Vim was, or any text based editor like Sublime Text or TextMate, which DHH still famously uses, uh, doesn't have the ability to, you know, like rename a model and have that propagate throughout the whole of your code base without, Find and replace manually.

Um, and so sometimes if I needed to do a more complex refactoring like that, I'll pull, uh, like a JetBrains IDE up like RubyMine or something. VS code has some of that tooling built in. I think. Sticking with Vim over the years is useful because Tim, you were just saying like across our technologies, you use that same setup and I was going to add as you kind of interjected that question, Dan, that one of the benefits that I find to having a very highly tuned setup like that is I could be building a React or a Gatsby, App, or I could be building a rails app or writing a Python script.

If I'm in my editor setup and Vim, it all still kind of feels roughly like programming to me and less like I'm writing a rails app or writing a react app. I mean, obviously there's nuance and there's syntax and there's ways that you structure the code or, make queries to the backend or whatever.

That's all very different and certainly lends itself to the overall development experience. But so much of. what we do, at least for now, is still manipulating text on the screen. And being able to do that in a consistent way and not having to, you know, only program a certain programming language in a certain development environment, I think really helps us as polyglots, uh, you know, at a consulting company, be able to jump around and, do different things and still remain productive.

Yeah, for sure.

Dan: and I think that there's something to be said about the productivity features that are built into it. I've. I'm certainly not opposed to jumping in and using an app like Sublime Text or VS Code currently, but like nothing ever feels quite the same. Maybe it's just like, I don't know, decades worth of, muscle memory built up, but being able to do things like record a macro really quickly to do a thing, right?

It's like once you hit that like higher level of abstraction with the tool, it feels like you can just do so much more quickly than you would be able to without having to reach for my mouse, right? Like I could probably all do, do all the same stuff in any of those other apps, but I'm going to be fiddling around clicking on things or clicking into

Jon: menus.

Yeah, definitely. I know you use Vim a lot, Dan, for the times I get to program still. I'm, I'm in Vim 95 percent of the time. Terminal based Vim. Tim, I know you're, you're in that same type of setup and we'll talk maybe a little bit either in this episode or another about Vim Some of the shared setup that we have with Astro and Vim and that's part of what I submitted in the talk was being able to have unified setup across the development team and a shared set of experiences and configurations that you can extend, but in general, folks should be able to sit down and be relatively comfortable with a setup at a company.

I think that's important. People have different opinions on that, right? Like everybody might, want to have their own very unique setup. And as long as when they're pairing, they're only dictating and nobody's driving anyone else's editor, that can be okay. But, any case, there's different philosophies there.

But Chris, I wanted to go to you because I know you prefer VS Code and you find that, very productive and useful. and I think famously you've dubbed yourself maybe the slowest typer at Hedway yet, still one of the fastest, uh, developers. So, it's clearly, it, it isn't all about just speed and yeah, just talk to us about your experience with VS Code and what keeps you there.

Sure. Yeah.

Chris: So I, I don't know, like I've never really had a, an editor that I've been like, this is my tool. I've just been like, what's the tool that's going to get me what I need to get done fastest. Um, and like, I don't have that muscle memory with Vim. I just have never developed it. I used it occasionally when I was like SSH ing into stuff and I needed to like, you know, edit something.

on like a running server or I needed to look at log files But I never used it as like a main editor. I used like sublime text and then I had Some of the jetbrain stuff I was working with for a while and then you know vs code was free So I started using that. Uh, so yeah, it's just I think it's like I don't want to say laziness on on that part of things But I guess it is like I would I want to get The like meaningful stuff done faster and like whatever gets me there, like even if I only have a shallow understanding of my editor, like I'm comfortable

Jon: with that.

it's an interesting thing. I think we find in our culture at Headway is there isn't a lot of bike shedding, right? It's like people just want to do good work. They genuinely enjoy programming and they like working together and with our clients. Right. And. You know, we don't sit and argue about this plugin or that gem or this package or, you know, whatever.

It's like, well, that, that seems like that'll work. Let's keep moving forward. Yeah. And yeah, I think you embody that well, Chris, where you're just like, Hey, I'm just happy to code. Like let's get some work done and, uh, we will be done at the end of the day. And but you still work on stuff on the side, on, on the weekends and you program for fun still, but.

It doesn't mean you need to be, you know, crazy about your editor. So, yeah, right. Interesting.

Any other editors people have been thinking about tinkering with or looking into besides the juggernauts of VS Code and Vim?

Dan: I dabble a lot in like the, like you're talking about the JetBrains stuff, but it's almost out of necessity from jumping into, Android projects, Android studios, kind of the thing.

And you're almost swimming upstream trying to not use it. You certainly can. Yeah. Um, I'm curious about, I think it's called app code. One of my iOS developer friends, told me that he's been using that primarily as his editor. Cause he's living in both an Android and an iOS app. they're doing a lot of, Kotlin multi platform code.

And so it's easier to just have it all be a monorepo and you can deal with it all inside of one spot. And I think that's interesting. I don't, I just haven't seen a need for it yet in the, projects that we're doing. But it's nice to know it's, it's out there as an option.

Jon: And I suppose you have to play in Xcode quite a bit too, Dan.

Yeah,

Dan: true. I do. And, um, it's funny because like all these editors have, A way to put like a Vim mode on. So Xcode actually has a built in, uh, Android studio. You have to go download a plugin, but there's certain things they all do it like to varying degrees of well. and so you really feel like this wall of like muscle memory hit you when you go to do something and there's a bug, like I think Xcode still has a bug where you try to do like a, single line gank, right?

So you select the entire line and. cut it or copy it to move it somewhere else. It'll copy the line below it too. you get used to working around those things, but it definitely makes me want to turn it off every now and then

Tim: that's so interesting, Dan.

And it's fascinating how many, programs have adopted them bindings or emac

Jon: bindings?

Tim: Like, it's just really interesting that that's. A thing that so many people want that authors of a program, add that feature, even in live book, there's been bindings or Emacs and being able to navigate between cells and edit without ever reaching for the mouse is just surprisingly fast and it feels really natural if you've already got that muscle memory built

Jon: up.

Yeah. Is there another. Experience and life that's akin to modal editing, where the majority of the population is always in insert mode in a Word doc or a Google doc, right? But developers who've stumbled upon Vim or Emacs or, other flavors of that kind of thing, kind of unlock this new level of multi mode editing, normal mode and insert mode.

I was trying to think like a steering wheel on a car, but that doesn't really apply. Like, is there any other thing in life

Dan: where, or a thing where it's very similar, even though it's still computer, right? You're still looking at the thing on the screen, but it's not programming necessarily, but it definitely sits in a really nice analog to that, where you have this multimodal setup of like, either I'm adding data or I'm navigating around or manipulating it at a much higher

Jon: level. That's interesting. I'd never really thought of a spreadsheet as almost like a Vim document, right? A normal mode with the, the arrows and then you hit enter to start typing in the cell.

Yeah, that's, that's definitely it. I was trying to think outside of A computer if there was just another experience in life that there's like this new layer that you unlock that all of a sudden then everybody who's ever had that experience only wants to do it that way, right? I don't know.

Yeah. VR maybe or something, right? Like, Oh, I never watch a movie if it's not, you know, 3d or in VR anymore or something, you know, anyway. Tim, you had mentioned, I think, this week in, Slack, something about, uh, the Zed editor. Is that something you've explored? Yeah. So

Dan: I,

Tim: this whole conversation is, uh, about appreciation for, them, at least for me.

Jon: Um,

Tim: but then I actually found myself in the last week or two reading and bumping into Zed in more and more references at least amongst the Elixir community, and a lot of it had to do with. The, language server just the out of the box experience you get with

Jon: a Zed. and so I was

Tim: fighting a little bit with language server in Vim at that point.

I thought, well, if this is going to give me the batteries included experience, why don't I give it a try? so I started to go down that, path. I didn't get very far only because I didn't have a lot of time.

Jon: but it was the first time in, I don't even know, a decade that I started to think.

Ah, maybe I'll try a different editor. So it's kind of funny to be having this conversation now. Do they have a concept of modal editing in Zed? I believe so. But again,

Tim: I barely scratched the surface in it's been spoken highly enough amongst folks that are following online.

Um, that, but others, it's like VS code, right? It's very, very well loved. It's very capable. There's absolutely nothing wrong with it. uh, the positive vibes that people give who use it daily was enough for me to look into

Dan: it further. Nice. Is this just another bullet point for like what the Erlang beam can do?

It's your server. It's your database. Now it's your editor

Jon: too. The beam's

Tim: coming for you.

Jon: Be careful.

Dan: Your bus, your plane, you

Jon: can do anything with it. Right.

So another thing that, came up this week was some decisions that Apple has made around, PWAs, Progressive Web Applications in the European Union. And I don't have a hundred percent of, The picture here, but from my understanding, there was an issue. I don't know if it was antitrust monopoly type thing where mobile Safari was being viewed as too much of the only choice, Apple needed to allow other rendering engines, um, to exist on the platform.

So for example, right now, until and unless this law is put in place in the EU, as well as, propagates potentially to the rest of the world. Up to this point, there was only Safari on iOS. Right. And then they allowed other browsers, so to speak, to exist, but they were all using the same web kit rendering engine under the hood, even if it was a Microsoft edge browser, it's.

Well, you know, it was the Safari rendering engine, the mobile iOS Safari rendering engine, and same for Firefox and anything else. So they could, I don't know, let you log in with your Firefox account and sync your bookmarks maybe. I'm not really a hundred percent sure what people found as super beneficial going outside of Safari on iOS specifically, um, on Android.

It's a, I think a different story, but on iOS now the EU has said, you have to open it up and say, Hey, Firefox can actually have its own rendering engine. Um, and all the other browser manufacturers can feel free to release an app in that.

area of the world. But of course, Apple giveth and Apple taketh away. And they said because of their sandboxed approach for mobile Safari being gone effectively now by allowing other browser rendering engines, to be on the platform. they're taking away the ability to add to home screen and have that be a PWA.

So if you add a bookmark to your home screen now, it'll open up just in the regular Safari view. And so much more limited in terms of what you can do. Push notifications go away, which really only came within the last year with iOS 16. 4. So that's gone. Um. Service worker, I think is severely hamstrung if not gone.

And it just seems like PWAs, unfortunately, aren't going to be a viable solution going forward for our clients. And so that was something that caught our attention in Slack and things that have had people talking about alternative approaches, what have you guys seen in that realm? Yeah, it's,

Dan: silly.

when it started cropping up initially, a lot of people were trying to figure out is this. like a chilling effect of, the EU's DMA law or is this just a bug, right? Did something slip by in this latest beta that broke it? Um, so Apple came out and kind of confirmed it yesterday through their language, which is really interesting that they, took this feature away with no communication.

And then I guess probably had to do a little bit of damage control afterwards. I don't know how they thought they weren't going to have to. And it really amounts to them saying. With all the changes the EU is requiring of us, it's just too hard to do this, which I think is, an absolute farce. I think there's plenty of other things you can point out that they've maintained over the years that are probably, you know, quite a bit of branching logic to maintain.

Um, so I think they're really trying to, in some ways, hold developers ransom for all these, other, things that they are having to, acquiesce on, which is unfortunate because I think the only people that really suffer are consumers. Um, certainly it impacts the type of work that we can do.

We've, been, uh, venturing into the world of PWAs more and more. And, it's a nice stepping stone for, you know, a founder or someone that wants to, build mobile application, but maybe at slightly more reserved budget, um, because can build your web app, but you can just kind of progressively level it up and add mobile like features and then decide if you really want to like venture into the world of mobile at all, or if it's good enough.

And now, if anybody wants to work with, Someone in the EU or in the EU country and develop an application like that, you pretty much know now that not going to work out for you. So that's really unfortunate.

Jon: Yeah. And to your point, they said, Oh, this would be too much work for us. And I think if I recall correctly, the work was in some sort of API or SDK to allow the other browsers to be sandboxed. Or something as well because there were issues potentially with being able to have credentials stolen between the browsers if you logged in on firefox and and then they just said oh yeah this is too hard i don't like it dan yeah it's

Dan: frustrating too because if they had opened up the ecosystem from the get go and allowed mobile browsers to You know, bring your own rendering engine and all the things that go along with it, it probably wouldn't be an issue.

You know, it would be Google or Mozilla or Opera or whoever's requirement to be a best in breed browser solution. And so with that, you would have to also do all the work required to implement a PWA system. Um, so it feels a little bit like a straw man to me. And maybe there's, I don't know, I'm trying not to put a tinfoil hat on, but it feels like they're trying to use it potentially as a bargaining chip in some way to try to force the EU to do something they want to do.

Jon: Yeah, or if it rolls out, it'll just force everybody to have to build 100 percent apps. they can charge for in app purchases of unlocking digital content. And as we've seen recently, even if you provide a way to pay off platform, they still want to audit you and Get their 27 percent instead of 30%.

Um, it's not going in a direction don't think that's Very favorable to developers, to clients, to end users, to anybody. Hopefully regulators

Dan: are looking at it from that same point of view. Cause it's very, feels

Jon: very anti consumer.

Yeah. So I mentioned Turbonative. That's another thing that's been, an area we've been delving into recently. Do you want to just give us a quick intro of what Turbonative is, Dan, and maybe where it could be beneficial if folks haven't heard about it.

Dan: Yeah. so tacking on to like what we just talked about, turbo native is a solution that allows you to, put, traditionally a Ruby on rails app, though, really it can be any app.

It hooks up with the turbo library and JavaScript and allows you to build a native iOS or a native Android app. that essentially is a, web view wrapper, which if anybody's ever built an app or used an app like that, you might already have the ick, but it's not quite that feels pretty fluid when you use it, and it gives you an escape hatch. So, other systems that might feel similar are things like ionic, which I think uses Cordoba. And, uh, I think Microsoft has a thing, maybe it's still around. but what Turbo Native really excels at is, a very standard set of interfaces with the Turbo JavaScript library.

mainly around navigation. So your backend app will present to your mobile app, configuration of how things should be routed. And then it can know, like, hey, if I tap. This link onto a profile, I should do this kind of transition, you know, if I tap on this little form, I can do a transition that pulls a modal up.

It allows you to like provide those native transitions that, we're used to using mobile apps, but all the content is actually rendered through a web view from, your back end. Like I said, rails is kind of the one that has promoted this, but, even the turbo native kind of example app is actually just like uh, I think it's like a node app or a next step that you pull down and run.

It's not running rails at all, which is really interesting. The other thing that you get out of the box recently that's landed this year is this newer feature called strata. And so what strata lets you do is essentially earmark part of your application to be replaced on device with a native view.

So where this can be really useful is maybe in your web app, you've got a hamburger button that pops up, like a menu drawer or something. You can replace that with a Native button. Um, so like in the iOS world, you have that navigation bar up there. It's pretty common and on Android, very similar, but the layout is, is somewhat different.

You can have it feel very native because it's an actual native control and that it does a little bit of a song and dance where it pushes data back to, your back end. And then since response back to your device to trigger more native actions. So we've used it in a few different projects and it's been really, really useful for popping up things like bottom sheets that have different select options or, um, trying to think what some of the other controls have been.

We've gotten, I think, alerts popped up like native alerts. Um, so it's been kind of a cool way to level up an app that already is built out from a web point of view. Into a Native app and have a really kind of easy on ramp into that ecosystem.

Jon: Yeah. We found it useful where you want feature parody between desktop and web and the ability to write that code once in a Rails app and then wrap it in Turbo native for iOS and Turbo, native for, for Android.

Um, is it called Turbo Native for Android as well? Dan? Mm-Hmm. . Same name? Yeah. Okay. Yeah. Turbo Native is like the

Dan: overarching, like methodology or architecture. And then Turbo iOS and Turbo Android are the. Yeah. Or the individual libraries.

Jon: Right. But it's been helpful to allow us to present options for our clients where we can say, to be able to take your idea and bring it to market in the most MVP form.

And it's a little different now with the PWA sort of, uh, constriction, uh, of capabilities and especially with the EU laws potentially rolling out wider, but you know, you could take it as a PWA. You could get. A somewhat limited, but still functional set of push notification capabilities. then add to home screen.

And so then it looks like an app once it's added that way. You can get some of those notifications and it really starts to feel like it's an app, but it's really just a mobile responsive website masquerading as an app. But then if you want to, you can level it up, right? So there's obviously different timelines and levels of effort and investment in these strategies, but it lets us present some options for here's where you could start.

Then you could go and wrap it around, TurboNative to get it into one or both stores. Obviously, there's work to do for each store. So if you only need to launch to iOS, you can save some money and investment by not having to build one for Android. And then from there, you have a, maybe a mapping component that's currently being rendered as a web view, and you want to level that up to be able to have it be more native and in the app.

Well, we're able to just then selectively replace some of the web capabilities with native capabilities, um, on a For route basis, which

Dan: is really nice. And maybe there's, you know, capabilities that there is no analog for necessarily on the web. So, um, I've done some experiments where I've renewed a list of different details.

And then when I tap on one of those details, I actually kick into an iOS AR view, right? Um, I think that kind of stuff more and more will become where the sweet spot of that tool is. Maps are kind of a no brainer because native experience for a map is always going to be significantly better than loading a map up in a web browser.

But then when we get into like this more mixed media audio video stuff, you really unlock the potential of what you could do with it. Which is nice because you can focus some developers attention at the thing that is maybe the most important right if you have an iOS developer, and a rails team, the rails team can get really far in a turbo native setup and the iOS developer could be working on that thing that really only they can deliver the value to to that project.

Jon: it's a really good hybrid approach, something, we're excited about continuing to explore. other thing that's interesting is I think, you know, TurboNative, Ruby on Rails, PWAs, um, we were founded on Rails back in 2015. That was the majority, if not all, of the work that we were doing. We've, of course, expanded since then we actually started, our path to React through React Native.

So we, we weren't building react web apps until we had react native mobile apps. And then we're like, well, I guess we could do this react thing as well. and then that lent itself to, well, sometimes we're only doing react because the client's team, for example, would have a node backend, with some end points and we would fetch data and hydrate some react components.

And then we're like, well, we could probably do some of that. Node backend work as well. And just kind of grew organically, our skill sets through the years and through folks that have joined the team, to broaden our horizons. And as a result, you know, Rails didn't necessarily take a backseat, but it wasn't the only hammer in our toolbox anymore.

But I feel like there's been this resurgence in Rails recently, we've been seeing some, posts on X of companies that are scrapping their existing tech stack and rewriting in Rails.

I've seen multiple of those, um, TurboNative certainly has helped, Rails 8 has helped, and, frankly, I think the Elixir live view capabilities that came out ahead of some of what we're seeing now in the Rails community really helped push. DHH and the Rails core team to level up their, web socket and real time capabilities too.

so it's been interesting to see, I guess, a little bit of a resurgence in popularity around Rails, and maybe it's just my echo chamber, but, um. I'm not the only one who's saying that. Maybe it's just the other people in my echo chamber saying that same thing. But, um, certainly it seems like there's some good momentum there.

And, along with the sort of pendulum swinging back to server rendered being in fashion now, um, it's that inevitable back and forth of More on the client, more on the server, more on the client. So, it's been interesting. Have you been noticing that same trend, Tim?

Yeah, I

Tim: have. I certainly see the amount of announcements coming in the Ruby community to be more consistent,

Jon: there's more anticipation building, not only

Tim: like excitement around the current. tech available, but some anticipation for what, Rails 8 will bring. Um, and yeah, haven't really felt that for a couple years, three or four years even.

It's, it's picked up. and yeah, I'm, I think as with anything, competition's good, right? So if wherever that innovation's coming from in the Ruby community, or Maybe the innovations always been there, but they kind of neglected marketing or promotion of it. I think it's in that game for everybody.

Um, it's interesting on the elixir side. I was listening to, Brian Cardarella give an update on live you native, on progress in that realm. And he was

Jon: providing a little bit of a

Dan: Very concise summary of

Tim: live you and now live you native, has some lineage back to react and the composable UI that react provides the managing state, and then having UI as simply representation of that state, that model, how developers really kind of fell in love with it, found

Jon: productivity with it, I think the react ecosystem

Tim: how fast that is, has shown that it's a.

very productive model, a lot of that, if not most of that has inspired what you see in live view. And so then that DocuArt crew is saying, well, let's take that same experience for web and see if we can apply it to native.

Jon: and then I think you see some reaction in the Ruby community to say, just what you pointed out, John, that, hey, this has some legs to it.

Tim: This has some promise to it. not only in Elixir, but we've already seen it play out in the React community. And so it'd be fascinating to see how that all, develops

Jon: and whether LibyNative, TurboNative, whether those ecosystems

Tim: grow, I guess in LibyNative's case, if they even establish themselves before they can grow.

But early

Jon: returns are promising for sure. Yeah, I mean it's exciting to see some of these technologies that have existed for a decade plus have some resurgence and excitement around. then we'd look at. the hype cycle of technology, right? Like, Rails was the darling in 2006 through, I mean, maybe a little bit later than that.

It was around in 04, 05, but kind of really gained popularity in, I would say, like, 2009 to 2014. somewhere in there. You know, then it waned a little bit, React certainly then shot up and became the new hype cycle and super exciting thing. And we build a ton of React apps and definitely have benefited from that technology's push of higher level fidelity experiences on the client.

And that's where the pendulum was very much swung toward the client to level up. And maybe the server couldn't do it, or maybe it was the internet connection speeds or myriad reasons. But I think that's what we go through in tech is. There's a hurdle. We overcome it a certain way. We realize that their hurdle maybe isn't there anymore after several years.

And then we kind of, look to see how we can change that and, and maybe reevaluate some of the assumptions that made that thing popular in the first place. So, Chris, do you think, have we reached? Peek React, like, is it, it's still going to be around for a very long time. And I think people will continue to choose it as the biggest piece of their app and the UI for the user to have a really good experience.

But do you think, are we starting to see it kind of calm down a little bit?

Chris: think so. So like the React team has been kind of quiet for the past couple of years.

Jon: Dan Abramov, am I saying that right? Uh, did he step down, I think, from maintaining React or his position at Facebook?

Chris: did, but now he's sort of back in like at least a limited role. Um, because he's talking a lot on Twitter about react server components and figuring out how to best explain them to people. Oh, but yeah, I think, a couple of weeks ago I probably would have said, yeah, maybe, but also like we have to consider that like the react ecosystem is like the largest developer ecosystem on the planet.

So it's going to be really hard to like, you know, it's like a big boat, you know, it's going to be really hard to get it to stop or really hard to get it even to turn around. And they still have, uh, you know, meta is still backing it. And like, when you compare like meta's open source contributions to any other companies.

Like it's, it's night and day. It's not even close. Like they invest very heavily in that. So I don't know. I mean, and I don't really know how much more that team actually wants to achieve after like React server components are out. Like what's that like React has never coined itself as a framework. It's always said it's just a library for, you know, displaying UI.

so really like. How much more can you do? Um, but as far as like the popularity of react, like it was definitely, uh, waning just because they hadn't done a major release in a while. Uh, but when react 19 comes out, maybe that'll spike back up. Who knows? I mean, the funny thing about like what we do is you can kind of build whatever you want with whatever you want.

It's like a lot, you know, a lot of it is, uh, it comes down to team and the sort of user experience ceiling that, uh, you're going to be comfortable

Jon: with. Or constraints of the project, right? We've had clients who, you know, in a highly regulated industry, in the financial or insurance industry, for example, they might have a bunch of existing data and a bunch of existing services.

And sure, we're creating something new, but it's a layer on top, like you said, UI for achieving a purpose with their existing data. And It probably doesn't make sense to go in there and use something like a full stack framework like, Rails, right? They really just need the ability to have a fresh new UI access existing data and maybe there's a middle layer that's Translating it or munging it slightly differently so that they can add some value to their existing data, but, um, you're not going to replace their back end.

and so we can come in use react and it's a perfect tool for a job like that.

Chris: yeah, exactly. if you've got a startup that's, you know, they've got. three months to do a build and they want, uh, a website built, that uses a database and that you're basically pulling stuff in and out of the database.

Like I, in that case, I, I don't know that we would always react, you know, maybe then, it sounds like a really good candidate for rails or elixir. but in these cases where we're dealing with existing clients and they have a bunch of data and they have some APIs and they just want a front end, like then react is a really good fit for that.

Even if we need to do some sort of backend for front end, uh, we can lean on next. and do that sort of lunging that you talked about earlier. So yeah, just comes down to a lot of like what the work is that comes in the door and what the, I guess what the parameters are.

Tim: Back to your point about meta and the amount of effort and resource support into open source contributions that the React 19 update that you had shared just earlier today. Um, I, one part of that, that really sad to me was the. Effort to improve how memoization works and remove the manual steps involved in that.

Um,

Jon: to me, that sounds like a pretty significant effort,

Tim: which gives me hope that their interest in

Jon: continuing to invest isn't waning to,

Tim: maybe I'm reading into that more than it needs to be, but I like that update because it

Jon: would greatly improve.

Tim: Documentation, the experience overall, performance, it would be a win, I think, for everybody.

Chris: Yeah, well, and I think that the, like, use memo, use callback stuff is, like, it's one of, it's some of the most confusing parts of, any React app, because you're not really sure when to use it, so, like, occasionally people just default to using it for everything, and I don't think that's the right answer, um, but, All the time that I've been writing react apps, there's been like three or four times where like I needed to use memo, or I needed to use a callback like all the other times it's been fast enough.

So it'll be nice to have the compiler, doing all that stuff behind the scenes so it'll kind of optimize it for you. so I definitely look forward to that and then like doing the server actions I think is going to be pretty cool too. And if you're using next right now like they're.

On the canary build. So they already have access to that. Um, so most of the next tutorials we'll show you kind of how that stuff works right now, if you're interested in checking it out.

Jon: Yeah. You said, Chris, we might not choose react for. A startup that, uh, that needs a full stack. But sometimes, I mean, depends on the situation, right? Like Dan, I think you're working on a project right now that would have been difficult to choose something like Phoenix or Rails. Uh, it's a browser extension that can do some auto filling.

And so you're using React in the extension on that, correct?

Dan: yeah, there's and we're using it on multiple parts of the stack there, right? So there's definitely a spot where we could have picked any technology. But, in this particular project, it feels very efficient to use react on both our front end and the Chrome extension because we get to stay in that same ecosystem, the same framework.

and we don't have to jump through any other special hoops to try to like pass messages across because at the end of the day, it all has to be JavaScript anyway. So it's been good. And the tooling is there. It's very, I mean, it's cool to see how, how flexible it is to do really whatever you needed to do.

Jon: And you're using not a full stack framework with a database back end on that one, but you're using sort of a back end as a service, right? Is that what you would call super base? Yes.

Dan: Yeah, for sure. Um, yeah. So super base if you're not familiar with it, I would imagine a lot of people are, but, um, it's essentially like a Firebase competitor, but a group, of people took the concepts that Firebase, promoted originally decided, like, what if this was open source?

And so that's what's. Cool about super bases, they took a lot of that stuff and instead of building it on top of a no SQL database, it's built on top of Postgres. So really what you could think about it as is like, hosted Postgres as a service plus a lot of other stuff. Um, so you get a dashboard with it to be able to do, any kind of data entry you need, like set up your tables and stuff.

But then you can layer things on top of it. So the way like in this particular project, we've got it. You know, your Chrome extension and your front end app that are going to integrate pretty tightly. but we're also able to just pull in a tool like motor admin and hook it up to the super base and provide a really flexible, nice back of house system for managing the tool at a high level, without really having to waste a lot of cycles building the same thing up from scratch that we've done over and over and over again.

Um, because that's not really where the value for our customer is. and Supabase has been cool. Tim, probably has some thoughts too, because he's been in working on it with me, but, Um, the thing that's nice about it is you won't bump into anything where you're like, Oh, I don't know how to solve this.

Like they have, there's an answer for every single problem you're going to run into. And they have a very nice, set of libraries that you can use in a variety of different languages, so. they provide access to your Postgres database through like a REST API interface. Um, but if you need a GraphQL, you can just turn on a feature that provides a GraphQL layer, which, you know, is depending on like your feelings about GraphQL, like you, that might not be good enough because any person with access to your dashboard can change your schema.

But that's the trade off I think you make for, that speed and that flexibility. Um, but what we're, the way we're using it is the, uh, the Supabase JS library, which is very similar to how you would use Firebase where you pull a library in, you set up your keys appropriately, um, and you're off to the races and they have a whole authentication package built in React that we can pull in and, um, we didn't have to do, Yeah.

Some of that, uh, both tedious and hard to get right work of building a whole authentication system and, login suite. Um, it's just there and it's kind of, it's open sourced, right? So there's a ton of people looking at that code, vetting it, making sure that it's doing all the right things. Um, and we can just drive right at the value, um, that they've engaged us to, to build for them.

Jon: Yeah, that's great. one of the reasons I love consulting is just being able to work in so many different verticals, so many different industries, use a lot of different technologies and. experiment. It's a little risky sometimes, and the smaller projects tend to be riskier because it's a smaller budget, it's a tighter timeline.

Um, we gotta make sure our assumptions are accurate and that we can get it right. whereas if we're iterating with the team for eight months, it's a lot. less risky because we're all learning together. Uh, by and large, if a client comes to us for a four week build, they assume we will be delivering almost a packaged piece of software that will just go work and make money.

So, uh, interesting to have to play on both sides of that spectrum, but, um, something, you know, I think we're going to continue to, to get better at with AI and with some of the smaller pieces of, tech and pieces of projects we can, we can deliver, um, but Hey, this has been a good discussion.

I think let's cut it there next time. I'd love to talk more about, AI and ML. I know we've been doing some things in that arena recently, both from a consumer standpoint by that, I mean, using it as. And users like in our development environments, we've also been building some applications that leverage AI and ML, to do various things that could help, um, the medical community is the first proof of concept that we've been building.

So we'll talk about that. I'd also like to learn more and talk with you all about cloud native and what that exactly means when, and if it might be a good fit for. One of our clients or somebody who fits the same persona as one of our clients and why we don't tend to use it all that much. Some of the downfalls or issues that can arise with a cloud native build that, for example, just to to whet the appetite, would leverage every aspect of AWS and not necessarily deploy to a virtual private server a full stack solution.

So, um. I think that'd be interesting to dig into and, chat with you guys about next week. That was great. All right. Well, thanks everybody. We'll talk to you next time. Bye.

‍