MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today we've got a few people here. We have Matt, Nathan, Ramses, and Bart. And we're here to talk about JavaScript a bit.
To give a little context, I've been doing web development for a while. I first started tinkering around with it back in the '90s. Back at that time, things were a little bit different. There was no such thing as front end, much of anything. The web was designed as kind of static documents that you would navigate between. So, in the early days, what you even think about as a web application, you had a website, and maybe you'd add a little bit of interactivity to your site. So you could do some things dynamically. But that was kind of a novel idea at the time.
So you'd go to a page, you'd request the page, and everything on the page would be built on the server, and they would send it from the server out to the browser. The browser would render it. And that was the paradigm. That was the paradigm for a long time. That's how it started. 1993, I believe, was the first web browser, although very few people were using it at the time.
And over the next, certainly the next 15 years after that, it was primarily done in kind of the same way. You'd make a request to a server. It would render that document. The document would be sent over the wire over to your browser. Your browser would then show it.
They came up with this language, JavaScript, that could run inside the browser, a little language. And at first, it was used for just doing tricky, little things like showing little decorations dancing around your mouse. [laughs] I remember that one back in the early days. And they mostly got rid of those because they were more of a distraction than actually helpful. People were just having fun.
But over time, people started to realize, well, maybe we could actually do some useful things with this language that gives us interactivity in the browser. And so they started doing things like allowing you to drag and drop, which was really useful compared to what happened before. And, you know, other sorts of interactivity where you get a little bit of animations, or maybe you click something, and you see something highlighted somewhere.
And that interactivity made the browser feel a little bit more like a desktop application. Well, over the last decade, that has really expanded. And we now have not just interactivity on websites but the whole idea of rendering has often been taken entirely away from the servers. The server is just a source of data, and the front end does all of the rendering. And that is a radical shift from the early days. And it was kind of hard-won because, you know, a lot of people would resist that because it breaks the paradigm. There are some changes there.
And Rails, the framework that I've done a lot of my career in, hasn't really moved along with that movement. They've kind of stayed; let's keep rendering on the server side. And they've come up with a whole kind of independent system for doing that, for sending real-time updates out to the client that are rendered on the server side so that the JavaScript can be kept minimal. It's kind of an opinion that they've expressed that is not shared by most of the web development community.
We're not in a goal here...[chuckles] not in the business of starting flame wars but rather talking about potential advantages and disadvantages of different approaches to technology.
I have with us here Nathan Pearson, who's spent a lot of his time working on the JavaScript front end, and he's doing so here at Acima. And so he's here to talk about the React way of doing things, you know, the JavaScript way of doing things and how that compares with kind of the traditional or the Rails way of doing things. So we can compare and contrast and kind of see the value that you might get from these approaches.
And that's kind of where I've started. I've started with my I've been doing this for a while talk [laughs] and shared a little history because it matters. And it kind of informs some of the debates people have because they have their history. So, Nathan, where would you kind of like to start with this?
NATHAN: Well, hey, thanks for having me, first of all. I guess maybe a good way to do this would be to describe if we're going to talk about a little bit of, like, compare and contrast with what Rails is doing versus what we see with other frameworks. Maybe we should talk about how Rails does it. And then I can get into a little bit more on the other side of things. But if you like, I can try to describe Hotwire to the best of my abilities. Although I'll admit, I'm not an expert in it, unless you'd like to do it if you've done a little bit of research on that or if you have some experience with it.
MIKE: I haven't used a lot of it but a little bit. And I think you kind of captured, like, even the name captures most of it. Hotwire is an acronym for HTML Over the Wire. So it's a framework that's designed to send markup, fully-built markup, like, fragments of the page over the wire out to the front end using WebSockets. So it's fast.
So there's some real-time communication with the rendering still happening on the server side so rather than the client side maintaining a full sense of the state of the document. That's really not handled on the client side. Rather, the server-side renders it, and the client side just kind of sticks the content where it goes, and that has its merit. You don't have to know JavaScript very much [laughs] if JavaScript is not a familiar language to you.
In a world where most people know JavaScript, maybe the advantage has diminished some. It keeps the paradigm that we've had for decades and doesn't force us to go into a JavaScript world. There are some advantages to that as well, including for accessibility. JavaScript sometimes isn't very good for accessibility.
NATHAN: Yeah, or for SEO, right? I mean, things rendered on the client. Yeah, I guess if I could, I'd maybe just add that...so as I understand Hotwire, you have kind of, like, the two...is there are two parts to it. They call it Turbo, which is kind of a mini framework that handles really a lot of sort of the unseen interactions on the Rail's side. And then you have the Stimulus, which allows you to kind of pepper in some JavaScript.
And I guess the big thing with Turbo is it's mostly built around Ajax, right? So it gives you this...I guess they call it unobtrusive interaction with JavaScript where you can sort of write most of your code still within Rails, kind of like as Ruby, using Ruby templates. And then you use certain directives to indicate that this is going to be an Ajax request, and really kind of just Rails handles it from there. You don't have to worry about how do you replace different components on the screen? That just kind of happens dynamically for you behind the scenes.
So I think that's one of the major advantages of it is that it sort of gets out of your way and lets you get your job done, like what you said, which is it gives you that more traditional way of thinking about working with the web as a document, instead of a dynamic application with a lot of moving parts. So it sort of simplifies that for you. But it gives you the benefit of being able to add dynamic sort of changes to your application without a page refresh. Would you agree? Is that a fair way of describing it?
MIKE: Yeah, I think it is. And, you know, for anybody who's not used Ajax, it's an old acronym for Asynchronous JavaScript...AJA...what is the name of the second A? It's [inaudible 07:07] for the JavaScript [inaudible 07:09] XMLHttpRequest. You can see why they...to shorten that XMLHttpRequest. [chuckles] I was around when they first started using that technique.
And Microsoft introduced this component in Internet Explorer back a couple of decades ago that allowed you to send XML, at the time, over the wire, and other browsers kind of cloned it. And it became the de facto way to send information between the browser and the server without having to do a full-page refresh. And it's only relatively recently that JavaScript has really kind of natively got that ability with the Fetch API.
MATT: Just those old days of building your own libraries for Ajax requests. It's sure come a long way since then.
MIKE: Yeah, it has.
NATHAN: Yeah. So I guess coming back to that just as far as laying the foundation for this talk, so, if we're looking at Hotwire, I would say that there's probably this scale, I guess, in my mind of on the one hand, you have more of, like, this classic way of working with web applications where you have a server-side rendered page that gets pushed out to a browser. And then, in the browser, you get JavaScript that gets sent as well. And then that then, you know, applies some interactivity on the page, so it's a little bit more dynamic.
On the other extreme of that, you have pure just JavaScript. So that page is rendered using JavaScript, whether it's in the client. It could, I guess, also be rendered server-side with JavaScript using Node. But JavaScript is really in the driver's seat of doing all of that.
And then I think from what I understand of Hotwire, you know, I haven't really worked with it, but it sort of falls in between those two. So it gives you some of the dynamic nature of JavaScript. But because it's still kind of wrapped within Rails as a full-stack application really focused on Ruby, it gives you the ability to sort of work with that and deliver a lot of that interactivity in kind of a classic way but with a lot of, you know, the modern features as well of making it really rich.
So it is an interesting proposition, but I'd say that's probably where it would fall in my mind is it's sort of in between these two extremes of how you may want to think about, you know, how web pages are delivered to a browser and where JavaScript kind of enters the scene.
MATT: Yeah, it may be worth noting as well that Turbo uses WebSockets, so event-driven.
NATHAN: Now, does Turbo always use WebSockets, or is that just the Turbo Streams part of it? Because as I understand it, Turbo is made up of three different pieces, you know, Turbolinks still plays a role, and it's just basic Ajax requests. But I'm not sure whether or not, I guess, I wasn't sure whether or not WebSockets are used universally with Turbo.
MIKE: I think it depends on kind of your usage. It's been evolving to this point. And I think you can rely primarily on WebSockets now. But you could still use kind of the classic Ajax-type techniques.
MATT: Yeah, you can go 100% the WebSocket route, but it is not required with Turbo.
NATHAN: Yeah, it's interesting. So, I'd say, coming back to this kind of other end of that extreme on the fully JavaScript side, I'd say probably React encapsulates that even more than any other purely JavaScript framework like Vue or Angular in that view. They kind of have their own built-in templating idea. They have what are called directives. So you will create some kind of HTML representation of what you, you know, eventually want to present out to the client.
And then you can add what they call directives on elements that are kind of baked in, or you can create custom directives that let you have certain interactions with those elements, whether it's managing their state, or replicating them, or looking into them in some way that allows JavaScript to control, you know, how those elements are managed on the screen.
React even goes further into JavaScript land where they use JSX, which is, like, a JavaScript representation of XML. Basically, it's just JavaScript will create all of your HTML. So it's not just your behavior, but it'll render your markup really similar to, I guess, what you would think of in terms of, like, I guess, ERB sort of does that. It actually does use HTML behind the scenes, but, like, the form builder and things like that that will create different HTML elements for you. React goes whole-hog with that. I mean, just everything is done with JavaScript. So there's some trade-offs there.
In terms of preference, I think I'd say some folks prefer having something like a Vue or an Angular, where you have these directives, this special kind of key attributes that are on these HTML elements. Some like the JSX approach. I do prefer personally the JSX approach just because it just feels like you have even more control. It's all JavaScript. And you can even do debugging statements directly in your markup, which you couldn't do, like, let's say, in Vue. So that's a really interesting sort of feature, and I'd say why I would probably categorize React on the most extreme end of, you know, really having JavaScript run your entire presentation.
MATT: Being able to debug in your markup is really powerful.
NATHAN: Yeah, it comes in handy when you're looping something. So you may want to check the state of your data as you're going through a loop. And it's a little hard to do that unless you can throw a debugger in there.
MIKE: There's also some strength in the idea that you never leave the language. You don't have two things [chuckles] where you have your language, and then you have your templating language. You just have your language. I think that is a real strength. You don't have the cognitive challenges of switching contexts.
NATHAN: Yeah, absolutely. And I think one of the issues with JavaScript that I struggle with, I mean, to date, is the toolchain. So, like, modern JavaScript doesn't look anything like what you end up delivering to your client, to the browser, when it gets, you know, pushed out into production. You have to transpile it down to sort of an older kind of more, I guess, like, acceptable sort of version where it's not...doesn't have all the modern bells and whistles.
The more, like, custom kind of templating, transpiling that you have to do things like with the Vue idea or with Angular where you have these directives and whatnot, there's just an additional layer of, you know, they call it pre-processing, getting it prepared for the web. So you just have to kind of stitch that into your toolchain and make sure that you configure that properly.
And it's just another, I guess, small point of failure if you're not, you know if you don't do that correctly. I mean, it's not a big deal. But it's just something to be aware of where everything is purely JavaScript. It just eliminates at least just that additional factor of having to juggle yet another plugin or a pre-processing library that you'd need to handle that stuff with.
MIKE: To take that a step further, most people don't write JavaScript anymore, right? They write TypeScript.
NATHAN: Yes, that's right. There's a new survey that came out for this year. Their claim is that in 2022, front-end developers, JavaScript developers, by and large, spent more time with TypeScript than they did with regular JavaScript, which is pretty impressive and understandable. I mean, if you've used TypeScript, you really can, you know, appreciate what type safety and, you know, the autocomplete sort of IntelliSense that you have while you're developing what that brings to the table. To be honest, after using it, it's kind of hard to go back to a language that doesn't have those features.
MATT: And it really helps you DRY up your code. And I was also just going to say something maybe to note is the configuration of these modern JavaScript libraries. You know, in the past, there wasn't really any configuration you had to do on your front end. But now you need to be aware of the configuration side of things as well.
NATHAN: Yeah, that ends up being kind of a big deal. And there are a lot of tools around that. The big one today is...they call it Vite, so it's spelled V-I-T-E. With React, at least, it used to be this tool called Create React App, which was built and maintained, and it's still out there. It just doesn't have that much usage anymore. But it was provided by Facebook, the same team that builds React. And it was just kind of like a one-button click starter pack for getting your React app up and running without having to worry about configuring tools like Webpack.
Vite sort of has the same thing. It's a little bit more flexible. It allows you to do this with Vue, or Angular, or React, or whatever framework you really want. It's not, you know, married to a specific framework like Create React App was. And it also allows you to modify your build process, this sort of pre-processing of JavaScript that you'd need, which is something you couldn't do with Create React App. That was always, like, a major complaint.
So, if you wanted multiple entry points, which, for example, if you're building a browser extension, you have multiple types of pages, you have a pop-up page. You have a background JavaScript page. You have what they call a content script. You'd need different entry points for those. And you couldn't really do that with Create React App. It just kind of assumed you just want a basic, you know, web page with React. So that was always, like, a big complaint, and Vite solves that. They allow you to be able to really kind of configure it the way that you want. It doesn't break any of the default configurations.
But you definitely need a tool like that these days if you're writing modern JavaScript, which is kind of a topic in and of itself. It's a radical departure from, let's say, things that I think we kind of grew up with, which is like, you know, the problems with the var keyword [chuckles] and stuff like that, and the various type of scoping problems that you'd see with JavaScript.
It's really changed quite a bit. They've introduced a module system, which gives you a proper namespacing system. You don't need to use those Immediately Invoked Function Expressions anymore to kind of contain your scope. So it's really come a long way as far as what, you know, the differences are.
MATT: You're actually the one that turned me on to Vite, and I have not looked back since making the change on any of my projects. So thank you for that.
And another great thing with some of these modern tools is live updates. That makes such a huge difference when you're making changes on the front end.
NATHAN: Oh yeah. It's huge. They call it the Hot Module Replacement where, you know, you make a change while you're developing. And you don't even have to refresh your screen; you just see it immediately. And, well, I'll tell you that that is such a pleasant development experience. It's really hard to appreciate that unless you do it, you know, and you see how elegant that is. It's just a...it's a really nice way to work.
MIKE: What I'm struck by as you're describing this, although it's not new, so front-end development is really becoming kind of like back-end development. [chuckles]
NATHAN: [laughs]
MIKE: There's this compilation process, right? You build a build, and you push it out. We started with front-end development being just little toys. And now it's really kind of the same deal as the back end was. And I think there are still a few folks out there who see front end as secondary, but it's kind of coming to its own, where it's the same basic processes we're doing for the backend.
NATHAN: Yeah, I mean, you can even go further with it and talk about Node, which is used for the back end. So there are full-stack frameworks like Next.js. I think there's also one called Remix that's sort of a similar type of deal where they're, I think, trying to creep into the Rails space. I mean, they're offering your full-on back-end layers of your stack, as well as the front end. But you don't ever leave the language. You're all in the same language, whether that's good or bad, I don't know.
I think as a developer, you always want to learn at least a few languages so that you can really kind of get a sense of what the differences are and understand kind of, you know, those trade-offs. But it is far more robust, I think than we certainly started with when we were talking about JavaScript.
MATT: Yeah, things like Next.js took a lot of cues from the Rails world, just the similarities, the dependency injection, things like that that are really great. And, you know, you said full stack. It makes it much easier to be full stack if you're using the same language across your stack instead of having to separate those language concerns. But full stack has definitely, I think, taken on a new meaning in the last, say, five years or so.
MIKE: You know, Rails was revolutionary in 2005, but that was getting to be quite a long time ago. The ideas that it spread out in the community have spread and have taken root elsewhere. So Rails really isn't the unique framework that it once was because just kind of best practices, the convention over configuration, or having a high-quality ORM have kind of spread everywhere. And I don't think that we should think that Rails is, wow, this is the only place you can get this anymore. Those ideas have gone elsewhere, and they've bounced around and sometimes improved.
MATT: Yeah, you can find them in almost every language now.
NATHAN: Yeah, so I use Node Express a lot of times for, like, a quick, you know, back end, if I have to put something together. It's less opinionated than Rails. I configure it so that it resembles Rails because just all of the patterns, MVC, for example. You know, whether you love it or hate it, there's something very familiar with understanding how to group your code up in the way that Rails does it. And I think it's just a quick way to get started.
A lot of the patterns that Rails introduced are so, you know, they're so, like, effective in terms of a mental model of how to work with a back-end system like that or a web system that they just carry over really well. And yeah, indeed, I see them a lot in a lot of different frameworks. I think Rails has been really kind of an inspiration for web development across the board.
MATT: I find myself doing the very same thing.
MIKE: So we've talked a little bit about...we kind of went on a direction there talking about the toolchain. But we haven't talked deeply about what are the compelling advantages of having, say, React that completely and, you know, and disadvantages. But tell me reasons to...advantages to having React manage everything so that no longer are you really running a browser web page but rather, you're running a web application using JavaScript that's managing everything that you see.
NATHAN: Yeah, I think it's a good topic, and it is helpful to juxtapose it with Rails. Not to bash on anything that Rails does, Rails does things in a different way. And it is possibly a matter of preference. But I think juxtaposing it with Rails...or there's Laravel and other frameworks similar to Rails that are still doing it in that way as well. So I think just thinking of whether you want to call that, like, the classic way, or kind of this sort of improved classic way of having a server-side rendered page with some unobtrusive dynamic JavaScript in there versus pure JavaScript.
What I would probably argue attracts me, at least for the React side of things, for the pure JavaScript way of doing things is, first, for me, I guess it's a matter of ergonomics, just the preference of working with React, or even if it was just pure Vanilla JavaScript, everything being in that world. So you have however you want to organize your code. You can co-locate it. You can think of it really kind of as its own independent unit. And you don't have to think about, you know, separating out these different parts that need to come together across the stack. You can kind of focus on it. So there are certain ergonomics that comes with that.
There's also the data sort of transfer part of it, you know, you're dealing with JSON data instead of HTML fragments. So that, to me, tends to...there's an attraction there. I guess it just tends to simplify it. And it tends to help me think about an application as being, well, I guess, the back end as being separated from the front end in terms of an API.
And when you kind of merge the two together into a single framework, that separation becomes pretty murky, and it's hard to sort of separate that out. So, you know, as your architecture grows and you have multiple services, and you may want to reach out across multiple services, you know, in my experience, it's just easier to work with JSON data or some sort of transactional data rather than actual fragments of a markup that you want to present in your code.
MATT: Yeah, I think that separation of concerns is huge. You know, it makes rebuilding a front end much simpler than if everything is tied together in a single, like, monolithic application.
I am curious to hear maybe some of the guys who haven't been doing it quite as long as us old folks in the room how they feel about the separation of concerns. Has it been harder for you guys to pick up on front-end development? What are your thoughts on that, if you have any?
RAMSES: Not any super strong opinions. I think it's just with any new language; you just need exposure to it and practice with it. I don't have a lot of practice with or a lot of experience with different JavaScript frameworks, a little bit with Stimulus and React now, and, I guess, Vite too; that's even less. [laughs] I think there's just so many different tools out there, so which one to go with is hard to say. Just find something that you like and learn it.
MATT: Yeah, sometimes picking is the hardest part.
MIKE: The specific thing that you were pointing out, I think, Nathan and Matt, you're both pointing out, which is that sending data in a consistent data-centric format between applications is better than sending document fragments that, you know, in a markup language is a better idea, I think that's a pretty compelling argument.
One of the reasons that the web was successful was that it separated presentation from the data. So a markup language like HTML...in some of the early days of the web, presentation started getting mixed in. You started getting tags that referred to style. And we had to kind of pull back from that where we don't have the tag anymore, for example, [laughs] if you remember that one.
Then we said, well, we're going to send you data. We're going to send you, you know, some markup, which is data that's notated, essentially. There's a description of the data, but it doesn't say how to present it. That's the browser's job. And so you just start with the data and let the browser figure that out. And if you want to determine presentation, well, you have a separate language for that. You have Cascading Style Sheets that describe what it looks like. And then, you have JavaScript that describes what the behavior is.
And by separating those concerns, we ended up getting away from the entanglements, and there's a lot better success in being able to conceive the problem. And even better than those document fragments, arguably, the markup still is a description of content.
But we could also send that in a different dedicated content language like JSON, where you have something that's more like just strings and integers, or Booleans. And if you're a lower level, then the browser can not only think about that as the document being in one format but maybe reformat that document and completely rethink it. And so it lets you go to a little bit deeper level and separate those concerns even more, which I think is a really great idea.
MATT: Yeah, and standardization is huge, right? Remember the days of building, like, SOAP APIs? And I have nightmares just thinking about that. But you can standardize things, and you expect something to come across as a different format. It really isolates it. And I think that is just a huge win.
MIKE: You don't write WSDLs for fun?
MATT: Yeah [vocalization]
MIKE: [laughs]
MATT: I [laughs] really do. I have nightmares of having to write SOAP API and WSDLs.
NATHAN: Yeah, that is definitely a huge deal. Like, especially when you're talking about your architecture growing and you want to think about, you know, having APIs. It's really difficult; I'd say, to do that. In a way, I'd almost argue that thinking in terms of a, you know, traditional view of what full stack means sort of limits you in terms of understanding how to really think about the API.
And, you know, if you really kind of just use the example of just building something like a class or a function even, if you think about that functions API, what kind of data is it going to take? What is its output going to be? At least I find myself when I'm faced with a problem that I need to solve; I think about it in those terms of, okay, I need to write this thing. And this is the way I want it to look. This is the way I want it to be consumed. This is the data that is going to come out of it.
And then the internal implementation, I mean, that just comes out as far as that's just the work of getting it to look like that, but the design really comes first. And when I think about, you know, systems and larger architectures, I think the same sort of thought process goes into modeling; what is your API? What data is it going to take? And what's the output going to be? And when you are really working with this full-stack approach, you tend not to find yourself in that mental model. You tend to think in terms of, okay, well, what's my UI going to look like? And, you know, so on and so forth. And I think that that has its place.
And, in some sense, this whole topic of data versus these fragments and whatnot they have their place as far as what you're trying to build. If it's an initial app, maybe even beyond a prototype, but you're out in the market, and you're kind of at a certain point in the lifecycle of your application that it makes a lot of sense to do it, you know, quickly, I think Rails serves that need really, really well.
But when you go beyond that, and you have multiple services, that model of having a purely full-stack framework that you're working with begins to get challenged a little bit. I'd probably throw that in as, like, one, you know, strong kind of distinction between these two paradigms of having this separation.
And I'd say the other part of this that kind of dovetails into it is, really, it's kind of a question of control. So Hotwire, what's really nice about it is that you don't really have to know very much JavaScript to really gain a lot of the advantages that JavaScript offers, modern JavaScript, right? Where you're able to refresh major chunks of the page or even smaller parts of the page dynamically without a page refresh.
But the issue that I have...and maybe this is a personal thing because I always tend to worry that, you know, what happens when I need more control? Especially if you're a newer developer and you're just starting out, and you're learning the Rails way of doing things, are you really going to understand how to debug a JavaScript issue that's baked into, you know, that Turbo framework? So that's the thing that I tend to be a little bit concerned about, leaning too much on that. Kind of it's such a nice abstraction, but it removes you so much from the bare metal of JavaScript that I would say you could run into certain issues while you're developing.
I'm also not sure whether or not...and I don't know if this is totally related to that point. But there's this concern, I guess, I have of whether or not it can handle all the use cases that I've seen, so like routing, for example, would be a big question for me. Like I said, I haven't used Hotwire, so I don't have the experience with it. But in the current app I'm building, there's, like, a stepper interface where you go through, like, a wizard from one step to another.
And those tend to be done...I've seen them done in multiple ways, one where the URL doesn't change. So the browser's history doesn't play a role. There's no routing at all. It's just the UI is purely changing. And then there are other cases where you may want that, whether it's for SEO reasons or whatever, you know, reasons you may want someone to be able to click into a specific, you know, pass a link somewhere and be able to click into a specific step, same thing with, like, an accordion interface.
I don't know how well a Hotwire would manage or allow you as a developer to manage, you know, that history and that URL change in between a UI like that. Maybe it would. And when I think about it, it seems like a pretty complicated case.
MIKE: I was talking to a friend the other day about another case that I think is also challenging for a framework just trying to avoid JavaScript, which is optimistic writes. That is, suppose you're looking at a list of things, and you...[inaudible 32:10] is looking at a list of things, and they want to delete one of them, say it's a task list. And they click to delete one.
If you have full control over the front end, you could delete that element from the page and then run the actual deletion in the background asynchronously. Think about it that way. And I think you could do that in something like Hotwire, but it's going to be challenging. But if you have a model of the document already, it's much easier to think about that kind of situation. And that, you know, you remove it from the page, and then the user gets instant results. And then if something goes wrong, well, then they get a notification, and maybe it comes back.
But the idea of being able to think about your document in that way, rather than having to be kind of chained to the back end at every step. That you can think about, you know, what if you want somebody to work offline? Why not just build a whole pool of updates that they will make once they get connected? And that is so far removed from requiring all of the rendering to be done on the server side. You know, I think it becomes utterly impractical.
One kind of unstated requirement of having something like Hotwire is that you're always connected because you rely on the server to do everything, which means that you're tightly coupled. And that coupling has some problems associated with it. Now, it may be hard to do things without being online, but I think there are some applications that it makes sense to be able to keep the user largely functioning without having to be always connected.
NATHAN: Yeah, absolutely. And that, to me, also dovetails into this whole issue of mobile. I know that Rails team is working on something right now for Hotwire where that will provide an answer to the mobile question, but I haven't seen that yet. In fact, I haven't really seen it with many frameworks. So there really isn't a mobile answer on the Vue side of things or Angular. React, however, does have that. And I'm sure that these other frameworks can follow a similar sort of model for it.
And that's one of the things that's also really attractive for me with React is that you may not be able to reuse all of your code, but you can reuse a good chunk of your code if you're building an application that needs to be delivered on different platforms. Mobile isn't the only thing. You can do desktop as well. So, you know, Slack, for example, is a JavaScript app run on Electron. So that can all be done with React.
And so you can imagine being able to...if you're a smaller kind of startup and you have a smaller team, you can build a lot of functionality that can be reused, you know, APIs, various services, and whatnot that you need to process data validations, various schemas. A lot of the plumbing that you would need and across all of these different platforms can be reused with some pretty minor changes on the, you know, the UI part of it.
So, you know, with mobile, you have a different UI concept. It would still be in React. You would just be using different sort of gesture and animation kind of libraries than you would from, like, a web UI. But even that, if you build your web UI, you can glean kind of how you've separated out your components and organized things and apply the same sort of hierarchy of structure of how state is managed and whatnot in the UI, even though it's using a slightly different framework. So you get a ton of that reuse.
I'd love to see how Rails answers that. Like I said, I know that they're working on something. I am curious how they're going to do it. But that is one thing that's currently lacking. And so, in some way, if you're talking about full-stack Rails, you miss a little bit of that control on the JavaScript end, and it really doesn't at least today, it doesn't have, you know, an answer to the mobile question.
MIKE: We've talked a lot about the advantages of the JavaScript front end. The other question, when might you want to go with something like Hotwire? I think you've just touched on something important, Nathan. You talked about, you know, you're a startup. You don't want to hire a bunch of people. And so you might want to keep your staff small. And sticking with one framework helps you do that. Does Rails provide that advantage in some circumstances? So, who would you recommend Rails to?
NATHAN: Yeah, I mean, absolutely. Like, you know, in our case, at Acima, when we first got started, I think Rails was the perfect fit. It still is in many situations where let's say; the UI doesn't change very frequently. It's pretty stable. And it doesn't have a ton of interactivity or demand from consumers. Maybe LMS would fall into that category. But the idea is, yeah, it can certainly, you know, serve a really meaningful sort of role within that kind of a context.
A startup with a small team of people that know the framework really well, who aren't really interested in, you know, some of these broader issues or these tangential issues that come up as you mature. They're just interested in getting the meat and potatoes up and running. And, oftentimes, even can live with those because that's good enough for the application. I think that Rails is probably, and still, I think, the leading framework to be able to do that.
MIKE: I think it gets you up and running quickly. If you only want to have people learn one thing, and that thing is pretty easy to learn, Rails is a great choice there. You mentioned LMS. For those listeners who probably don't know what that is, it's just an internal tool and things like that where you're not going to have a lot of updates to the UI. It makes sense. You probably want to keep it simple.
MATT: You can just get to market so quickly with a Rails application. It's always been my go-to if I want to quickly prototype something or just get something out because it's time-critical. It's powerful, and it's fast.
NATHAN: And there's also the language preference issue, right? I mean, Ruby is such an elegant, beautiful language. It's not just easy to learn. It's really just easy to work with. It does so many things in such a right way that it's just really just pleasant from a developer experience.
There are things in which, you know, I wish that they can add in a way that makes sense. I think they're trying to add some type safety to it. I haven't really played with any of that. And from what I've looked at in blogs and whatever, I don't know if I just intuitively got it right away by looking at it. But it'd be nice if that was something that found its way properly in the language and, in the framework, a bit of a different topic. But outside of that, I mean, you know, Ruby is just a fantastic language. So I think if you have a preference for that, Rails is just such a natural, elegant complement to it.
MIKE: Yeah, so I'm with you. If you want to get something up quickly, Rails is still, I think, a very compelling option. As you grow, it might be worth considering rethinking the front end. I'm speaking to Rails developers out there. [laughs] Rails does some great things, but it's not the only way. In fact, it's become kind of a niche, idiosyncratic way of doing things on the front end.
And because React has just been very useful, you know, it's a useful option that has largely taken over front end because it works. There's always somewhat of the hype train where people do it because other people are doing it. But there have been a lot of options for front end for a long time. People have not been locked down into one option versus the other. And they've stuck with React because it works. That model of thinking about the front end as being as serious of a thing as your back end has some real merit in a lot of circumstances, I think.
NATHAN: Agreed.
MIKE: I think we've covered some really central points. [chuckles] When you're thinking about the front end, the value of using a framework like React for front-end rendering and the decoupling that it gives you, the advantages of thinking API first.
We've also talked a little bit about how it breaks the traditional web paradigm. In some ways, that's still broken. Things like SEO and accessibility still haven't been entirely solved yet because the web was not designed that way. There's still some growth that needs to happen for us to get there. And if you want to get quick to market, maybe that's still not the best way to go. So there are advantages and disadvantages to everything. Now there's another tool to maybe consider putting in your belt [laughs] so that you can use it for the next problem you address.
And thank you, and we'll talk to you. You'll hear from us anyway next time.
To give a little context, I've been doing web development for a while. I first started tinkering around with it back in the '90s. Back at that time, things were a little bit different. There was no such thing as front end, much of anything. The web was designed as kind of static documents that you would navigate between. So, in the early days, what you even think about as a web application, you had a website, and maybe you'd add a little bit of interactivity to your site. So you could do some things dynamically. But that was kind of a novel idea at the time.
So you'd go to a page, you'd request the page, and everything on the page would be built on the server, and they would send it from the server out to the browser. The browser would render it. And that was the paradigm. That was the paradigm for a long time. That's how it started. 1993, I believe, was the first web browser, although very few people were using it at the time.
And over the next, certainly the next 15 years after that, it was primarily done in kind of the same way. You'd make a request to a server. It would render that document. The document would be sent over the wire over to your browser. Your browser would then show it.
They came up with this language, JavaScript, that could run inside the browser, a little language. And at first, it was used for just doing tricky, little things like showing little decorations dancing around your mouse. [laughs] I remember that one back in the early days. And they mostly got rid of those because they were more of a distraction than actually helpful. People were just having fun.
But over time, people started to realize, well, maybe we could actually do some useful things with this language that gives us interactivity in the browser. And so they started doing things like allowing you to drag and drop, which was really useful compared to what happened before. And, you know, other sorts of interactivity where you get a little bit of animations, or maybe you click something, and you see something highlighted somewhere.
And that interactivity made the browser feel a little bit more like a desktop application. Well, over the last decade, that has really expanded. And we now have not just interactivity on websites but the whole idea of rendering has often been taken entirely away from the servers. The server is just a source of data, and the front end does all of the rendering. And that is a radical shift from the early days. And it was kind of hard-won because, you know, a lot of people would resist that because it breaks the paradigm. There are some changes there.
And Rails, the framework that I've done a lot of my career in, hasn't really moved along with that movement. They've kind of stayed; let's keep rendering on the server side. And they've come up with a whole kind of independent system for doing that, for sending real-time updates out to the client that are rendered on the server side so that the JavaScript can be kept minimal. It's kind of an opinion that they've expressed that is not shared by most of the web development community.
We're not in a goal here...[chuckles] not in the business of starting flame wars but rather talking about potential advantages and disadvantages of different approaches to technology.
I have with us here Nathan Pearson, who's spent a lot of his time working on the JavaScript front end, and he's doing so here at Acima. And so he's here to talk about the React way of doing things, you know, the JavaScript way of doing things and how that compares with kind of the traditional or the Rails way of doing things. So we can compare and contrast and kind of see the value that you might get from these approaches.
And that's kind of where I've started. I've started with my I've been doing this for a while talk [laughs] and shared a little history because it matters. And it kind of informs some of the debates people have because they have their history. So, Nathan, where would you kind of like to start with this?
NATHAN: Well, hey, thanks for having me, first of all. I guess maybe a good way to do this would be to describe if we're going to talk about a little bit of, like, compare and contrast with what Rails is doing versus what we see with other frameworks. Maybe we should talk about how Rails does it. And then I can get into a little bit more on the other side of things. But if you like, I can try to describe Hotwire to the best of my abilities. Although I'll admit, I'm not an expert in it, unless you'd like to do it if you've done a little bit of research on that or if you have some experience with it.
MIKE: I haven't used a lot of it but a little bit. And I think you kind of captured, like, even the name captures most of it. Hotwire is an acronym for HTML Over the Wire. So it's a framework that's designed to send markup, fully-built markup, like, fragments of the page over the wire out to the front end using WebSockets. So it's fast.
So there's some real-time communication with the rendering still happening on the server side so rather than the client side maintaining a full sense of the state of the document. That's really not handled on the client side. Rather, the server-side renders it, and the client side just kind of sticks the content where it goes, and that has its merit. You don't have to know JavaScript very much [laughs] if JavaScript is not a familiar language to you.
In a world where most people know JavaScript, maybe the advantage has diminished some. It keeps the paradigm that we've had for decades and doesn't force us to go into a JavaScript world. There are some advantages to that as well, including for accessibility. JavaScript sometimes isn't very good for accessibility.
NATHAN: Yeah, or for SEO, right? I mean, things rendered on the client. Yeah, I guess if I could, I'd maybe just add that...so as I understand Hotwire, you have kind of, like, the two...is there are two parts to it. They call it Turbo, which is kind of a mini framework that handles really a lot of sort of the unseen interactions on the Rail's side. And then you have the Stimulus, which allows you to kind of pepper in some JavaScript.
And I guess the big thing with Turbo is it's mostly built around Ajax, right? So it gives you this...I guess they call it unobtrusive interaction with JavaScript where you can sort of write most of your code still within Rails, kind of like as Ruby, using Ruby templates. And then you use certain directives to indicate that this is going to be an Ajax request, and really kind of just Rails handles it from there. You don't have to worry about how do you replace different components on the screen? That just kind of happens dynamically for you behind the scenes.
So I think that's one of the major advantages of it is that it sort of gets out of your way and lets you get your job done, like what you said, which is it gives you that more traditional way of thinking about working with the web as a document, instead of a dynamic application with a lot of moving parts. So it sort of simplifies that for you. But it gives you the benefit of being able to add dynamic sort of changes to your application without a page refresh. Would you agree? Is that a fair way of describing it?
MIKE: Yeah, I think it is. And, you know, for anybody who's not used Ajax, it's an old acronym for Asynchronous JavaScript...AJA...what is the name of the second A? It's [inaudible 07:07] for the JavaScript [inaudible 07:09] XMLHttpRequest. You can see why they...to shorten that XMLHttpRequest. [chuckles] I was around when they first started using that technique.
And Microsoft introduced this component in Internet Explorer back a couple of decades ago that allowed you to send XML, at the time, over the wire, and other browsers kind of cloned it. And it became the de facto way to send information between the browser and the server without having to do a full-page refresh. And it's only relatively recently that JavaScript has really kind of natively got that ability with the Fetch API.
MATT: Just those old days of building your own libraries for Ajax requests. It's sure come a long way since then.
MIKE: Yeah, it has.
NATHAN: Yeah. So I guess coming back to that just as far as laying the foundation for this talk, so, if we're looking at Hotwire, I would say that there's probably this scale, I guess, in my mind of on the one hand, you have more of, like, this classic way of working with web applications where you have a server-side rendered page that gets pushed out to a browser. And then, in the browser, you get JavaScript that gets sent as well. And then that then, you know, applies some interactivity on the page, so it's a little bit more dynamic.
On the other extreme of that, you have pure just JavaScript. So that page is rendered using JavaScript, whether it's in the client. It could, I guess, also be rendered server-side with JavaScript using Node. But JavaScript is really in the driver's seat of doing all of that.
And then I think from what I understand of Hotwire, you know, I haven't really worked with it, but it sort of falls in between those two. So it gives you some of the dynamic nature of JavaScript. But because it's still kind of wrapped within Rails as a full-stack application really focused on Ruby, it gives you the ability to sort of work with that and deliver a lot of that interactivity in kind of a classic way but with a lot of, you know, the modern features as well of making it really rich.
So it is an interesting proposition, but I'd say that's probably where it would fall in my mind is it's sort of in between these two extremes of how you may want to think about, you know, how web pages are delivered to a browser and where JavaScript kind of enters the scene.
MATT: Yeah, it may be worth noting as well that Turbo uses WebSockets, so event-driven.
NATHAN: Now, does Turbo always use WebSockets, or is that just the Turbo Streams part of it? Because as I understand it, Turbo is made up of three different pieces, you know, Turbolinks still plays a role, and it's just basic Ajax requests. But I'm not sure whether or not, I guess, I wasn't sure whether or not WebSockets are used universally with Turbo.
MIKE: I think it depends on kind of your usage. It's been evolving to this point. And I think you can rely primarily on WebSockets now. But you could still use kind of the classic Ajax-type techniques.
MATT: Yeah, you can go 100% the WebSocket route, but it is not required with Turbo.
NATHAN: Yeah, it's interesting. So, I'd say, coming back to this kind of other end of that extreme on the fully JavaScript side, I'd say probably React encapsulates that even more than any other purely JavaScript framework like Vue or Angular in that view. They kind of have their own built-in templating idea. They have what are called directives. So you will create some kind of HTML representation of what you, you know, eventually want to present out to the client.
And then you can add what they call directives on elements that are kind of baked in, or you can create custom directives that let you have certain interactions with those elements, whether it's managing their state, or replicating them, or looking into them in some way that allows JavaScript to control, you know, how those elements are managed on the screen.
React even goes further into JavaScript land where they use JSX, which is, like, a JavaScript representation of XML. Basically, it's just JavaScript will create all of your HTML. So it's not just your behavior, but it'll render your markup really similar to, I guess, what you would think of in terms of, like, I guess, ERB sort of does that. It actually does use HTML behind the scenes, but, like, the form builder and things like that that will create different HTML elements for you. React goes whole-hog with that. I mean, just everything is done with JavaScript. So there's some trade-offs there.
In terms of preference, I think I'd say some folks prefer having something like a Vue or an Angular, where you have these directives, this special kind of key attributes that are on these HTML elements. Some like the JSX approach. I do prefer personally the JSX approach just because it just feels like you have even more control. It's all JavaScript. And you can even do debugging statements directly in your markup, which you couldn't do, like, let's say, in Vue. So that's a really interesting sort of feature, and I'd say why I would probably categorize React on the most extreme end of, you know, really having JavaScript run your entire presentation.
MATT: Being able to debug in your markup is really powerful.
NATHAN: Yeah, it comes in handy when you're looping something. So you may want to check the state of your data as you're going through a loop. And it's a little hard to do that unless you can throw a debugger in there.
MIKE: There's also some strength in the idea that you never leave the language. You don't have two things [chuckles] where you have your language, and then you have your templating language. You just have your language. I think that is a real strength. You don't have the cognitive challenges of switching contexts.
NATHAN: Yeah, absolutely. And I think one of the issues with JavaScript that I struggle with, I mean, to date, is the toolchain. So, like, modern JavaScript doesn't look anything like what you end up delivering to your client, to the browser, when it gets, you know, pushed out into production. You have to transpile it down to sort of an older kind of more, I guess, like, acceptable sort of version where it's not...doesn't have all the modern bells and whistles.
The more, like, custom kind of templating, transpiling that you have to do things like with the Vue idea or with Angular where you have these directives and whatnot, there's just an additional layer of, you know, they call it pre-processing, getting it prepared for the web. So you just have to kind of stitch that into your toolchain and make sure that you configure that properly.
And it's just another, I guess, small point of failure if you're not, you know if you don't do that correctly. I mean, it's not a big deal. But it's just something to be aware of where everything is purely JavaScript. It just eliminates at least just that additional factor of having to juggle yet another plugin or a pre-processing library that you'd need to handle that stuff with.
MIKE: To take that a step further, most people don't write JavaScript anymore, right? They write TypeScript.
NATHAN: Yes, that's right. There's a new survey that came out for this year. Their claim is that in 2022, front-end developers, JavaScript developers, by and large, spent more time with TypeScript than they did with regular JavaScript, which is pretty impressive and understandable. I mean, if you've used TypeScript, you really can, you know, appreciate what type safety and, you know, the autocomplete sort of IntelliSense that you have while you're developing what that brings to the table. To be honest, after using it, it's kind of hard to go back to a language that doesn't have those features.
MATT: And it really helps you DRY up your code. And I was also just going to say something maybe to note is the configuration of these modern JavaScript libraries. You know, in the past, there wasn't really any configuration you had to do on your front end. But now you need to be aware of the configuration side of things as well.
NATHAN: Yeah, that ends up being kind of a big deal. And there are a lot of tools around that. The big one today is...they call it Vite, so it's spelled V-I-T-E. With React, at least, it used to be this tool called Create React App, which was built and maintained, and it's still out there. It just doesn't have that much usage anymore. But it was provided by Facebook, the same team that builds React. And it was just kind of like a one-button click starter pack for getting your React app up and running without having to worry about configuring tools like Webpack.
Vite sort of has the same thing. It's a little bit more flexible. It allows you to do this with Vue, or Angular, or React, or whatever framework you really want. It's not, you know, married to a specific framework like Create React App was. And it also allows you to modify your build process, this sort of pre-processing of JavaScript that you'd need, which is something you couldn't do with Create React App. That was always, like, a major complaint.
So, if you wanted multiple entry points, which, for example, if you're building a browser extension, you have multiple types of pages, you have a pop-up page. You have a background JavaScript page. You have what they call a content script. You'd need different entry points for those. And you couldn't really do that with Create React App. It just kind of assumed you just want a basic, you know, web page with React. So that was always, like, a big complaint, and Vite solves that. They allow you to be able to really kind of configure it the way that you want. It doesn't break any of the default configurations.
But you definitely need a tool like that these days if you're writing modern JavaScript, which is kind of a topic in and of itself. It's a radical departure from, let's say, things that I think we kind of grew up with, which is like, you know, the problems with the var keyword [chuckles] and stuff like that, and the various type of scoping problems that you'd see with JavaScript.
It's really changed quite a bit. They've introduced a module system, which gives you a proper namespacing system. You don't need to use those Immediately Invoked Function Expressions anymore to kind of contain your scope. So it's really come a long way as far as what, you know, the differences are.
MATT: You're actually the one that turned me on to Vite, and I have not looked back since making the change on any of my projects. So thank you for that.
And another great thing with some of these modern tools is live updates. That makes such a huge difference when you're making changes on the front end.
NATHAN: Oh yeah. It's huge. They call it the Hot Module Replacement where, you know, you make a change while you're developing. And you don't even have to refresh your screen; you just see it immediately. And, well, I'll tell you that that is such a pleasant development experience. It's really hard to appreciate that unless you do it, you know, and you see how elegant that is. It's just a...it's a really nice way to work.
MIKE: What I'm struck by as you're describing this, although it's not new, so front-end development is really becoming kind of like back-end development. [chuckles]
NATHAN: [laughs]
MIKE: There's this compilation process, right? You build a build, and you push it out. We started with front-end development being just little toys. And now it's really kind of the same deal as the back end was. And I think there are still a few folks out there who see front end as secondary, but it's kind of coming to its own, where it's the same basic processes we're doing for the backend.
NATHAN: Yeah, I mean, you can even go further with it and talk about Node, which is used for the back end. So there are full-stack frameworks like Next.js. I think there's also one called Remix that's sort of a similar type of deal where they're, I think, trying to creep into the Rails space. I mean, they're offering your full-on back-end layers of your stack, as well as the front end. But you don't ever leave the language. You're all in the same language, whether that's good or bad, I don't know.
I think as a developer, you always want to learn at least a few languages so that you can really kind of get a sense of what the differences are and understand kind of, you know, those trade-offs. But it is far more robust, I think than we certainly started with when we were talking about JavaScript.
MATT: Yeah, things like Next.js took a lot of cues from the Rails world, just the similarities, the dependency injection, things like that that are really great. And, you know, you said full stack. It makes it much easier to be full stack if you're using the same language across your stack instead of having to separate those language concerns. But full stack has definitely, I think, taken on a new meaning in the last, say, five years or so.
MIKE: You know, Rails was revolutionary in 2005, but that was getting to be quite a long time ago. The ideas that it spread out in the community have spread and have taken root elsewhere. So Rails really isn't the unique framework that it once was because just kind of best practices, the convention over configuration, or having a high-quality ORM have kind of spread everywhere. And I don't think that we should think that Rails is, wow, this is the only place you can get this anymore. Those ideas have gone elsewhere, and they've bounced around and sometimes improved.
MATT: Yeah, you can find them in almost every language now.
NATHAN: Yeah, so I use Node Express a lot of times for, like, a quick, you know, back end, if I have to put something together. It's less opinionated than Rails. I configure it so that it resembles Rails because just all of the patterns, MVC, for example. You know, whether you love it or hate it, there's something very familiar with understanding how to group your code up in the way that Rails does it. And I think it's just a quick way to get started.
A lot of the patterns that Rails introduced are so, you know, they're so, like, effective in terms of a mental model of how to work with a back-end system like that or a web system that they just carry over really well. And yeah, indeed, I see them a lot in a lot of different frameworks. I think Rails has been really kind of an inspiration for web development across the board.
MATT: I find myself doing the very same thing.
MIKE: So we've talked a little bit about...we kind of went on a direction there talking about the toolchain. But we haven't talked deeply about what are the compelling advantages of having, say, React that completely and, you know, and disadvantages. But tell me reasons to...advantages to having React manage everything so that no longer are you really running a browser web page but rather, you're running a web application using JavaScript that's managing everything that you see.
NATHAN: Yeah, I think it's a good topic, and it is helpful to juxtapose it with Rails. Not to bash on anything that Rails does, Rails does things in a different way. And it is possibly a matter of preference. But I think juxtaposing it with Rails...or there's Laravel and other frameworks similar to Rails that are still doing it in that way as well. So I think just thinking of whether you want to call that, like, the classic way, or kind of this sort of improved classic way of having a server-side rendered page with some unobtrusive dynamic JavaScript in there versus pure JavaScript.
What I would probably argue attracts me, at least for the React side of things, for the pure JavaScript way of doing things is, first, for me, I guess it's a matter of ergonomics, just the preference of working with React, or even if it was just pure Vanilla JavaScript, everything being in that world. So you have however you want to organize your code. You can co-locate it. You can think of it really kind of as its own independent unit. And you don't have to think about, you know, separating out these different parts that need to come together across the stack. You can kind of focus on it. So there are certain ergonomics that comes with that.
There's also the data sort of transfer part of it, you know, you're dealing with JSON data instead of HTML fragments. So that, to me, tends to...there's an attraction there. I guess it just tends to simplify it. And it tends to help me think about an application as being, well, I guess, the back end as being separated from the front end in terms of an API.
And when you kind of merge the two together into a single framework, that separation becomes pretty murky, and it's hard to sort of separate that out. So, you know, as your architecture grows and you have multiple services, and you may want to reach out across multiple services, you know, in my experience, it's just easier to work with JSON data or some sort of transactional data rather than actual fragments of a markup that you want to present in your code.
MATT: Yeah, I think that separation of concerns is huge. You know, it makes rebuilding a front end much simpler than if everything is tied together in a single, like, monolithic application.
I am curious to hear maybe some of the guys who haven't been doing it quite as long as us old folks in the room how they feel about the separation of concerns. Has it been harder for you guys to pick up on front-end development? What are your thoughts on that, if you have any?
RAMSES: Not any super strong opinions. I think it's just with any new language; you just need exposure to it and practice with it. I don't have a lot of practice with or a lot of experience with different JavaScript frameworks, a little bit with Stimulus and React now, and, I guess, Vite too; that's even less. [laughs] I think there's just so many different tools out there, so which one to go with is hard to say. Just find something that you like and learn it.
MATT: Yeah, sometimes picking is the hardest part.
MIKE: The specific thing that you were pointing out, I think, Nathan and Matt, you're both pointing out, which is that sending data in a consistent data-centric format between applications is better than sending document fragments that, you know, in a markup language is a better idea, I think that's a pretty compelling argument.
One of the reasons that the web was successful was that it separated presentation from the data. So a markup language like HTML...in some of the early days of the web, presentation started getting mixed in. You started getting tags that referred to style. And we had to kind of pull back from that where we don't have the tag anymore, for example, [laughs] if you remember that one.
Then we said, well, we're going to send you data. We're going to send you, you know, some markup, which is data that's notated, essentially. There's a description of the data, but it doesn't say how to present it. That's the browser's job. And so you just start with the data and let the browser figure that out. And if you want to determine presentation, well, you have a separate language for that. You have Cascading Style Sheets that describe what it looks like. And then, you have JavaScript that describes what the behavior is.
And by separating those concerns, we ended up getting away from the entanglements, and there's a lot better success in being able to conceive the problem. And even better than those document fragments, arguably, the markup still is a description of content.
But we could also send that in a different dedicated content language like JSON, where you have something that's more like just strings and integers, or Booleans. And if you're a lower level, then the browser can not only think about that as the document being in one format but maybe reformat that document and completely rethink it. And so it lets you go to a little bit deeper level and separate those concerns even more, which I think is a really great idea.
MATT: Yeah, and standardization is huge, right? Remember the days of building, like, SOAP APIs? And I have nightmares just thinking about that. But you can standardize things, and you expect something to come across as a different format. It really isolates it. And I think that is just a huge win.
MIKE: You don't write WSDLs for fun?
MATT: Yeah [vocalization]
MIKE: [laughs]
MATT: I [laughs] really do. I have nightmares of having to write SOAP API and WSDLs.
NATHAN: Yeah, that is definitely a huge deal. Like, especially when you're talking about your architecture growing and you want to think about, you know, having APIs. It's really difficult; I'd say, to do that. In a way, I'd almost argue that thinking in terms of a, you know, traditional view of what full stack means sort of limits you in terms of understanding how to really think about the API.
And, you know, if you really kind of just use the example of just building something like a class or a function even, if you think about that functions API, what kind of data is it going to take? What is its output going to be? At least I find myself when I'm faced with a problem that I need to solve; I think about it in those terms of, okay, I need to write this thing. And this is the way I want it to look. This is the way I want it to be consumed. This is the data that is going to come out of it.
And then the internal implementation, I mean, that just comes out as far as that's just the work of getting it to look like that, but the design really comes first. And when I think about, you know, systems and larger architectures, I think the same sort of thought process goes into modeling; what is your API? What data is it going to take? And what's the output going to be? And when you are really working with this full-stack approach, you tend not to find yourself in that mental model. You tend to think in terms of, okay, well, what's my UI going to look like? And, you know, so on and so forth. And I think that that has its place.
And, in some sense, this whole topic of data versus these fragments and whatnot they have their place as far as what you're trying to build. If it's an initial app, maybe even beyond a prototype, but you're out in the market, and you're kind of at a certain point in the lifecycle of your application that it makes a lot of sense to do it, you know, quickly, I think Rails serves that need really, really well.
But when you go beyond that, and you have multiple services, that model of having a purely full-stack framework that you're working with begins to get challenged a little bit. I'd probably throw that in as, like, one, you know, strong kind of distinction between these two paradigms of having this separation.
And I'd say the other part of this that kind of dovetails into it is, really, it's kind of a question of control. So Hotwire, what's really nice about it is that you don't really have to know very much JavaScript to really gain a lot of the advantages that JavaScript offers, modern JavaScript, right? Where you're able to refresh major chunks of the page or even smaller parts of the page dynamically without a page refresh.
But the issue that I have...and maybe this is a personal thing because I always tend to worry that, you know, what happens when I need more control? Especially if you're a newer developer and you're just starting out, and you're learning the Rails way of doing things, are you really going to understand how to debug a JavaScript issue that's baked into, you know, that Turbo framework? So that's the thing that I tend to be a little bit concerned about, leaning too much on that. Kind of it's such a nice abstraction, but it removes you so much from the bare metal of JavaScript that I would say you could run into certain issues while you're developing.
I'm also not sure whether or not...and I don't know if this is totally related to that point. But there's this concern, I guess, I have of whether or not it can handle all the use cases that I've seen, so like routing, for example, would be a big question for me. Like I said, I haven't used Hotwire, so I don't have the experience with it. But in the current app I'm building, there's, like, a stepper interface where you go through, like, a wizard from one step to another.
And those tend to be done...I've seen them done in multiple ways, one where the URL doesn't change. So the browser's history doesn't play a role. There's no routing at all. It's just the UI is purely changing. And then there are other cases where you may want that, whether it's for SEO reasons or whatever, you know, reasons you may want someone to be able to click into a specific, you know, pass a link somewhere and be able to click into a specific step, same thing with, like, an accordion interface.
I don't know how well a Hotwire would manage or allow you as a developer to manage, you know, that history and that URL change in between a UI like that. Maybe it would. And when I think about it, it seems like a pretty complicated case.
MIKE: I was talking to a friend the other day about another case that I think is also challenging for a framework just trying to avoid JavaScript, which is optimistic writes. That is, suppose you're looking at a list of things, and you...[inaudible 32:10] is looking at a list of things, and they want to delete one of them, say it's a task list. And they click to delete one.
If you have full control over the front end, you could delete that element from the page and then run the actual deletion in the background asynchronously. Think about it that way. And I think you could do that in something like Hotwire, but it's going to be challenging. But if you have a model of the document already, it's much easier to think about that kind of situation. And that, you know, you remove it from the page, and then the user gets instant results. And then if something goes wrong, well, then they get a notification, and maybe it comes back.
But the idea of being able to think about your document in that way, rather than having to be kind of chained to the back end at every step. That you can think about, you know, what if you want somebody to work offline? Why not just build a whole pool of updates that they will make once they get connected? And that is so far removed from requiring all of the rendering to be done on the server side. You know, I think it becomes utterly impractical.
One kind of unstated requirement of having something like Hotwire is that you're always connected because you rely on the server to do everything, which means that you're tightly coupled. And that coupling has some problems associated with it. Now, it may be hard to do things without being online, but I think there are some applications that it makes sense to be able to keep the user largely functioning without having to be always connected.
NATHAN: Yeah, absolutely. And that, to me, also dovetails into this whole issue of mobile. I know that Rails team is working on something right now for Hotwire where that will provide an answer to the mobile question, but I haven't seen that yet. In fact, I haven't really seen it with many frameworks. So there really isn't a mobile answer on the Vue side of things or Angular. React, however, does have that. And I'm sure that these other frameworks can follow a similar sort of model for it.
And that's one of the things that's also really attractive for me with React is that you may not be able to reuse all of your code, but you can reuse a good chunk of your code if you're building an application that needs to be delivered on different platforms. Mobile isn't the only thing. You can do desktop as well. So, you know, Slack, for example, is a JavaScript app run on Electron. So that can all be done with React.
And so you can imagine being able to...if you're a smaller kind of startup and you have a smaller team, you can build a lot of functionality that can be reused, you know, APIs, various services, and whatnot that you need to process data validations, various schemas. A lot of the plumbing that you would need and across all of these different platforms can be reused with some pretty minor changes on the, you know, the UI part of it.
So, you know, with mobile, you have a different UI concept. It would still be in React. You would just be using different sort of gesture and animation kind of libraries than you would from, like, a web UI. But even that, if you build your web UI, you can glean kind of how you've separated out your components and organized things and apply the same sort of hierarchy of structure of how state is managed and whatnot in the UI, even though it's using a slightly different framework. So you get a ton of that reuse.
I'd love to see how Rails answers that. Like I said, I know that they're working on something. I am curious how they're going to do it. But that is one thing that's currently lacking. And so, in some way, if you're talking about full-stack Rails, you miss a little bit of that control on the JavaScript end, and it really doesn't at least today, it doesn't have, you know, an answer to the mobile question.
MIKE: We've talked a lot about the advantages of the JavaScript front end. The other question, when might you want to go with something like Hotwire? I think you've just touched on something important, Nathan. You talked about, you know, you're a startup. You don't want to hire a bunch of people. And so you might want to keep your staff small. And sticking with one framework helps you do that. Does Rails provide that advantage in some circumstances? So, who would you recommend Rails to?
NATHAN: Yeah, I mean, absolutely. Like, you know, in our case, at Acima, when we first got started, I think Rails was the perfect fit. It still is in many situations where let's say; the UI doesn't change very frequently. It's pretty stable. And it doesn't have a ton of interactivity or demand from consumers. Maybe LMS would fall into that category. But the idea is, yeah, it can certainly, you know, serve a really meaningful sort of role within that kind of a context.
A startup with a small team of people that know the framework really well, who aren't really interested in, you know, some of these broader issues or these tangential issues that come up as you mature. They're just interested in getting the meat and potatoes up and running. And, oftentimes, even can live with those because that's good enough for the application. I think that Rails is probably, and still, I think, the leading framework to be able to do that.
MIKE: I think it gets you up and running quickly. If you only want to have people learn one thing, and that thing is pretty easy to learn, Rails is a great choice there. You mentioned LMS. For those listeners who probably don't know what that is, it's just an internal tool and things like that where you're not going to have a lot of updates to the UI. It makes sense. You probably want to keep it simple.
MATT: You can just get to market so quickly with a Rails application. It's always been my go-to if I want to quickly prototype something or just get something out because it's time-critical. It's powerful, and it's fast.
NATHAN: And there's also the language preference issue, right? I mean, Ruby is such an elegant, beautiful language. It's not just easy to learn. It's really just easy to work with. It does so many things in such a right way that it's just really just pleasant from a developer experience.
There are things in which, you know, I wish that they can add in a way that makes sense. I think they're trying to add some type safety to it. I haven't really played with any of that. And from what I've looked at in blogs and whatever, I don't know if I just intuitively got it right away by looking at it. But it'd be nice if that was something that found its way properly in the language and, in the framework, a bit of a different topic. But outside of that, I mean, you know, Ruby is just a fantastic language. So I think if you have a preference for that, Rails is just such a natural, elegant complement to it.
MIKE: Yeah, so I'm with you. If you want to get something up quickly, Rails is still, I think, a very compelling option. As you grow, it might be worth considering rethinking the front end. I'm speaking to Rails developers out there. [laughs] Rails does some great things, but it's not the only way. In fact, it's become kind of a niche, idiosyncratic way of doing things on the front end.
And because React has just been very useful, you know, it's a useful option that has largely taken over front end because it works. There's always somewhat of the hype train where people do it because other people are doing it. But there have been a lot of options for front end for a long time. People have not been locked down into one option versus the other. And they've stuck with React because it works. That model of thinking about the front end as being as serious of a thing as your back end has some real merit in a lot of circumstances, I think.
NATHAN: Agreed.
MIKE: I think we've covered some really central points. [chuckles] When you're thinking about the front end, the value of using a framework like React for front-end rendering and the decoupling that it gives you, the advantages of thinking API first.
We've also talked a little bit about how it breaks the traditional web paradigm. In some ways, that's still broken. Things like SEO and accessibility still haven't been entirely solved yet because the web was not designed that way. There's still some growth that needs to happen for us to get there. And if you want to get quick to market, maybe that's still not the best way to go. So there are advantages and disadvantages to everything. Now there's another tool to maybe consider putting in your belt [laughs] so that you can use it for the next problem you address.
And thank you, and we'll talk to you. You'll hear from us anyway next time.
