Rails World Is So Good

Conferences are a wild ride—behind every event is a mountain of work and costs that most people never see.

This is something I've been wanting to watch: 1 hour in 5 minutes of David Heimer Hansen. I think I said his middle name—no, I don't know if anyone can say his middle name correctly, but here we go!

First, I want to say thank you to Amanda Pino and the entire team behind this incredible organization of this conference. I had no idea just how much work went into this until I saw it from the inside, and it is nuts how much effort goes into organizing conferences. By the way, conferences are insane for those who have never been a part of one.

I asked a question on Twitter because I was curious; people always complain about conferences having too much sponsorship. So, I had to ask: How much would you pay for a ticket? People were out there saying things like, “Oh dude, $200!” or “Amazing, $100!” Did you know that at a lot of conferences, to even have Wi-Fi, the lowest price I ever heard for 3 megabits up and 3 megabits down was $155,000 for a singular day? That is the lowest price I have ever heard. For those who have no idea how intense it is to actually do conferences, it’s crazy!

You can't get things plugged in; the unions and the Wi-Fi cartel run them. It is wild! You cannot touch or move anything; it's a whole different world. The effort it takes to put on a show like this is absolutely incredible. The fact that Amanda also managed to time the weather together with Rails 8 releasing here is just fantastic. So, thank you to Amanda and the entire team.

Now, by the way, I am not a Rails guy, so I don't know a lot about Rails or even Ruby. I'm not really a Ruby person, so this will be very interesting. The topic of today is Rails 8, and I am going to dive into all the wonderful new features and libraries and everything we have going on. It is one of the most exciting releases of Rails that I can remember. We have to go back at least until Rails 7 for me to have been this excited about a new release of Rails.

I want to spend a little time talking about Rails 7 because it sort of set a new tone, in my opinion, for where the framework is going. I have to pause for a second—I haven't been this excited about a release since the last release. This is crazy! For a while, we were taking cues from the rest of the world and realizing that the front end is moving in one direction and the cloud is moving in another. We just have to follow along.

However, I had a growing sense of unease with that sense of following because I thought there were a lot of parts along that path that didn't make sense to me. It wasn't the right way to go, but I didn't have a proper way to articulate that yet. For years, I had that brewing sense that we could do better. Even at the launch of Rails 5, when we integrated Webpacker, I thought, “You know what? This is something we just have to do.” It's not necessarily something I'm super excited to do.

Well, Rails 7 brought back that excitement, and it felt like there was finally an opportunity to realize a vision that had been growing for a very long time. Can we rewind for a second? Do we have any Rails champions in here? By the way, Goatmeal, I appreciate the five gifted subs!

Just a quick question: when he says Webpacker, is he referring to Webpack? Was Rails 5 attempting to be more like a modern JavaScript front-end type of framework? Is this where the transition from Rails 5 to Rails 8 is moving away from all of that?

Yes and no. Webpacker is a gem that wraps Webpack for Rails. So, to be clear, Rails 5 was much more about going towards a modern JavaScript style of doing things, whereas Rails 8 is like going away from all of that. Rails 7 and even Rails 8 are not really going in that direction.

That's kind of how I'm interpreting what he's saying—that Rails 5 was going one direction and Rails 8 was going the other. I just wanted to clarify because, you know, again, I don't know a lot of the lore about Rails. Rails has never been my area for a long time.

=> 00:05:30

Rails is evolving, moving away from outdated patterns to embrace modern web technologies, making development faster and more efficient.

In the discussion about the evolution of Rails from version 5 to version 8, there is a notable transition in how modern JavaScript frameworks are approached. Rails 5 was more aligned with the modern JavaScript front-end style, while Rails 8 seems to be moving away from that direction. This shift is particularly highlighted by the introduction of Webpacker, which is described as a gem that wraps Webpack for Rails.

To clarify, Rails 7 and Rails 8 do not fully embrace the modern JavaScript paradigm as Rails 5 did. The speaker expresses a desire to understand this transition better, admitting a lack of familiarity with the historical context of Rails, which has not been their primary focus for a long time. They aim to create a roadmap for future releases of Rails that can instill confidence in developers, using the concept of a pattern language as a guiding principle. This pattern language consists of a problem, context, solution, and consequences.

The speaker reflects on the aspects of the web that they found unappealing, noting that many patterns felt outdated and marked for garbage collection, yet had not been removed. They emphasize that Rails 7 represented a significant change in context due to advancements in web technology. This included the introduction of ES6 JavaScript, which became effective in the browser without the need for transpilation, as well as the impact of HTTP/2, which eliminated the necessity to bundle resources into large units. Additionally, the advent of import maps allowed for writing modern code directly for the browser.

The conversation then shifts to the technical details of HTTP/2. The speaker explains that in HTTP/1, requests and responses operate on a simple model where a TCP connection is established, and a keep-alive header is used to maintain that connection for subsequent requests. In contrast, HTTP/2 begins with a packet that contains a specific length and allows for multiple requests to be sent over a single connection. The only limitation is that while transferring headers, only one request can be processed at a time, but the rest can be multiplexed.

They describe how HTTP/2 improves efficiency by separating headers from the body of messages and using a streamlined method for handling requests. This results in a more efficient communication process, as it allows for faster request and response cycles without the blocking issues associated with HTTP/1. The speaker acknowledges that while developing with HTTP/2 can be both more challenging and easier, the overall goal is to facilitate rapid and simultaneous request handling, thereby enhancing the web development experience.

In conclusion, the speaker notes that the previous pattern of opening multiple connections to the browser has been invalidated by the advancements brought by HTTP/2, marking a significant evolution in web technology and its integration with frameworks like Rails.

=> 00:09:35

Embrace the evolution of web development: outdated patterns are holding you back. Simplify your approach and adapt to the new context for a smoother coding experience.

In the realm of web development, strings can sometimes lack content, making it necessary to discover how content length is determined or how it is chunked in coding. Instead of dealing with these complexities, there is a more straightforward style of messaging that simply indicates how big it is. This approach tends to simplify the development process, making it easier to work with. However, developing within this framework can be both harder and easier at the same time.

There are numerous misconceptions surrounding HTTP/2, but the primary goal is to enable super fast request-response cycles while allowing multiple requests to be processed simultaneously, without the blocking issues associated with HTTP/1. The pattern of invalidation that emerged from this shift was quite evident. Previously, developers were limited to opening four connections to the browser and had to wait for one to complete before opening another. This led to a bundling pattern where developers believed that browsers struggled with JavaScript, prompting them to transpile their ideas into more efficient JavaScript. However, advancements in technology have rendered these ideas obsolete.

As software developers, we have historically struggled with two main issues. One crucial point to consider is that if you have 3,000 files in a larger JavaScript project, managing them can be quite challenging. For instance, you might have around 2,100 index.js files, which can be difficult to open in an editor like VS Code. The advantage of a no-build process, as described, is that each file has a hash associated with it. When a file is changed, only that hash is updated, making it easier for the browser to manage downloads. Most files can remain cached indefinitely, and only the few that change need to be redownloaded. This results in a more efficient caching mechanism.

Conversely, with bundling, developers must split their bundles based on logical boundaries, depending on how files are required. This limitation means that changing one file could necessitate redownloading a significant portion of the app, which is less efficient. However, there is an argument to be made for larger files, as they allow for better gzipping and compression, potentially leading to improved load times, especially on the first load.

A point of curiosity arises when considering the load time over an extended period, particularly in a development environment with multiple developers and numerous changes throughout the year. It raises the question of whether this approach results in a lower footprint for actual downloads. This is an intriguing aspect that merits measurement.

Returning to the topic of cache invalidation, it is essential to address the mental models associated with it. The context of ES6, HTTP/2, and even import maps should have been embraced years earlier, rather than relying on cumbersome build pipelines that became the norm. This context has since been rediscovered, revealing that many previously established patterns no longer hold relevance.

Many people mistakenly believe that large companies operate simply by using tools like npm create Vite app. However, anyone involved in a sizable company with numerous developers understands that their JavaScript build system often evolves into a complex web of plugins and configurations, making it a cumbersome process. Build systems can become as complicated, if not more so, than CMake, which can be quite frustrating.

Initially, the process may seem straightforward, but the emergence of Hotwire represents a new, simpler method for writing JavaScript that aligns with backend development. This approach is well-suited for the context of 2024, unlike previous patterns that were more applicable to 2012 or earlier, before the industry had navigated through the necessary complexities of modern development.

=> 00:13:57

Building JavaScript systems shouldn't feel like climbing a never-ending ladder of complexity; embrace simpler, proven solutions like Hotwire to make coding fun again.

Developers know that their JavaScript build system becomes this entire giant ladder of creations of various plugins and ways you need to do stuff. All of that complexity can be a significant pain, and build systems have become as complicated, if not more complicated, than CMake. It becomes awful. However, at first, it seems very simple.

For part of the answer to that new context, Hotwire offers a new, simpler, and more modest way of writing JavaScript that integrates well with your backend. It works in this new context and is pattern fit for 2024. This is a stark contrast to the patterns that were suitable for 2012 or earlier, a time before we navigated through the necessary jungle of complexity that allowed us to reach a simpler place.

To clarify, I have never used Hotwire. My work has focused on other technologies. Hotwire is effectively HTMX with just a bit more control. For those who believe that Hotwire, HTMX, or similar frameworks eliminate the need to write JavaScript, let me assure you that you are mistaken. In reality, JavaScript becomes quite enjoyable to write when you can choose where to implement caching on the server and where to handle it on the client. This approach contrasts with a model that views the server and client as one, resulting in a giant amalgamation of state being transferred in confusing ways.

The complexity of the patterns you use can be overwhelming, and you may find yourself hoping that caching works as expected. Instead, having straightforward and precise caching on both sides simplifies the process. Additionally, rendering on the client is not as expensive as some might think. When you render JSON, it can be as expensive, if not more so, than rendering HTML. While I don't have 100% proof of this, I am quite confident due to how templates work and the intricate string manipulation involved.

In contrast, JSON requires you to traverse actual objects and extract keys and values, which adds complexity. Therefore, I am not convinced that rendering is significantly faster in one method over the other. However, you are correct that running React on the server is indeed more expensive than simply running JSON. I would agree with that statement, depending on how you frame the discussion around rendering on the server.

Both Hotwire and the process of identifying which patterns of today are no longer relevant have always been driven by extraction. We are not in the business of creating speculative frameworks in the Rails community; rather, we focus on taking solutions that have proven effective in real applications with real customers under genuine production pressures. We then package these solutions nicely as gifts and share them.

It's important to note that updating DOM elements is more expensive in Ruby than in React. However, that statement can be misleading because you don't update DOM elements in Ruby; you produce HTML. The cost of this process is difficult to quantify, as I have never measured Ruby against React. This comparison is challenging due to the different runtimes and various ways to write Ruby that can produce outputs of differing complexity.

Ultimately, these are the kinds of discussions that require running in production with tens of thousands, if not millions, of users to determine what is truly faster. If speed is your primary concern, you should consider using Go, Rust, or Zig—anything but JavaScript or Ruby. That makes perfect sense. If you're deeply concerned about speed, you're likely not using JavaScript; you're using something else entirely.

My work on Hey was a path that led to the discovery of new patterns and the validation of the notion that the whole industry might be wrong. It echoes the sentiment of that meme: "Is everyone wrong?" The answer is often, "No, everyone must be wrong." This was essentially the premise of Rails.

=> 00:18:01

If you're focused on speed, stop using JavaScript and Ruby; embrace the new era of no-build environments and challenge the outdated norms of web development.

At that point, you're already arguing the wrong thing if you're really deeply concerned about speed. If speed is your primary concern, you should use Go, Rust, Zig, or anything else; you don't use JavaScript or Ruby. That makes perfect sense; it's that simple. If you're that concerned about speed, you're just not using JavaScript; you're using something else. You're not using Ruby; you're using something else entirely.

My work on Hey was a path that led to the discovery of new patterns and the validation of a significant idea: the whole industry is wrong. This sentiment echoes the meme, "Is everyone wrong?" The answer is no; it must be, "Well, am I wrong, or is everyone wrong?" No, everyone must be wrong. This was essentially the premise of Rails 7's approach to the front end: everyone is wrong. We do not have to accept heavy build pipelines, bundling, or tree shaking as facts of modern web building. We can write a different story.

Can we all just agree that the complexity of including Lodash correctly to get tree shaking and all these different things is just frustrating? It’s incredibly annoying that we have to conform our import statements to ensure the least amount of possible code inclusion. Just because we can do it, it doesn't mean it's great that we can. It’s wild that we have to jump through so many hoops just to eliminate dead code. That was what we accomplished with the creation of Hey.

Interestingly, I started working on Hey in 2018 and saw some of these trends coming, but it wasn't ready yet. Even at the launch of Hey in 2020, it wasn't quite there. We had structured our things around Hotwire, but we were still using Webpack at the launch. It took about a year before we could fully realize these ideas and move forward. In fact, it was not until yesterday that we were able to go 100% no build for all of Hey. There is no build line in the JavaScript, and there is no build pipeline in the CSS.

Just for a moment, I want everyone to sit and think about that development environment. How awesome must that be? You know that no matter what you do, no matter how great your build system is, not having a build system means a lot slower code? No, it doesn't necessarily mean that. To be completely fair, there is an argument to be made that minified JavaScript is faster than parsing because parsing is an O(n) operation. So, there is something to that; you'll technically use less memory by having shorter variable names. I know that sounds crazy, but that's just life in JavaScript land.

Imagine how amazing this would be: everything is served directly to the browser as we wrote it. The benefit for me in doing this is not just the personal satisfaction of realizing these patterns and new ways of thinking; it is also to provide an irrefutable anchor point for the discussion about whether this is even possible on the internet. There is an endless cacophony of people telling you that the thing you're trying to do will not work—that it will not work in the real world, with real users, or with real customers. They will just not tolerate that.

The best way to refute that is not to get into an argument; it is to ship working software. Once you've shipped that working software, you have a monument to the argument that is simply immovable. You can claim that "no build" doesn't work for you, but you can't claim that it doesn't work at all. We have proven that it’s a great mentality.

By the way, I've had more than one experience at Netflix where I had to go around management and what people said I could or could not do, and just do it despite their objections. When I did it and showed the results, they were like, "Oh, actually, this is a good idea." Sometimes, you just have to do things because people will argue against a straw man that they have created in their heads or have heard was bad. You end up with entire parts of software that you can't turn off because you think, "Oh no, we already know this is bad." But then you have to ask: when was the last time you measured? Life has changed vastly; think about the difference in internet speed from 2012.

=> 00:22:21

Sometimes you have to break the rules to prove the naysayers wrong; innovation thrives when we challenge outdated assumptions.

In our work, we have proven that it's a great mentality. By the way, I’ve had more than one instance at Netflix where I had to go around management and what people said I could or could not do. I just did it, despite people telling me I should not do it. When I showed the results, they were like, “Oh, actually this is a good idea.” Sometimes, you just have to do things because people will argue against a straw man that they have created in their head or have heard was bad. As a result, you end up with entire parts of software that you can't turn off because everyone thinks, “Oh no, we already know this is bad.” But then you have to ask, “But why?” When was the last time you measured?

Life has changed vastly. Think about the difference in internet speed from 2012 till now. Consider the difference in the amount of bandwidth you can just shoot up and down. A lot of the assumptions we’ve had have shifted significantly, yet we haven’t really adapted to what is the new normal. I think of the yearly tweet from Toby as the perfect embodiment of this phenomenon. For 20 years, people have told us that Rails do not scale. In November of last year, Toby tweeted about doing 1 million requests a second on the largest Rails app in the world. This tweet serves as a monument that says, “Shut the [ __ ] up; this argument has been settled.” We don’t need to rehash this; just see the tweet.

To be fair, you could use a lot fewer servers using Go or Rust; you could use a lot fewer servers using a compiled language. This is true and factual. However, this is where the true argument lies: you create an environment in which some developers are really happy and want to be there. There are people who love writing Go and would hate writing Ruby, while others love writing Ruby. I don’t argue against the love of something. Some people love JavaScript, but I’m more convinced that most people love JavaScript because they’ve never actually tried something else. They do it because this is what they’ve always done and they’re just super familiar with it.

Many haven’t gone through the process of really learning something else. JavaScript typically is the first language a lot of people learn in the last 10 years, so they haven’t actually gone through the process of changing their opinion or mindset around something. Even for me, I got good at writing Go, but it took me about three months before I truly understood it. It was a very gradual adjustment for my brain. It takes time. At the end of the day, if that’s what you really love, you can just do that, and you don’t have to care what people say is good or bad. If you can write good software, then it doesn’t really matter what language you choose. If you can’t write good software, then it doesn’t matter either.

Now, let’s talk about the tangible benefits. This is how JavaScript loading looks. There are no source maps; there is no bundling. We are shipping everything straight to the browser. We wrote it out, and if you look closely, you can see something interesting. Look at the numbers attached to each one of these elements. Those numbers represent caching. That’s how they do caching: when they upload it to the CDN, they have these little processes that help it get downloaded properly.

I assume how it works, though I’ve never actually tried this no-build approach. You have your list of JavaScript imports, like import Fu, import Bar, import Baz. Then you have an import list where Fu equals Foo with some sort of hash at the end, and Bar equals Bar with a hash at the end. This way, your code never changes when you have to change Fu, Bar, or Baz, but the underlying code for Fu, Bar, or Baz changes along with the import map. This creates a highly cachable experience where you’re only replacing a couple of kilobytes at a time.

=> 00:26:20

The web's true power lies in its simplicity and backward compatibility; let's not sacrifice learning for minification and complexity.

When they upload it to the CDN, they actually have these little things that run through, and this helps it get downloaded properly. So, you have this process that I assume works in a certain way. I've never actually tried this no-build approach, but I assume you have your list of your JavaScript files that include imports like import Fu, import bar, and import baz. Then, you have an import list that looks something like Fu equals Foo with a hash, and bar equals bar with some sort of hash at the end. This means your code never changes when you have to change Fu, bar, or baz, but the underlying code for Fu, bar, or baz changes along with the import map. This way, you achieve a highly cachable experience where you're only replacing a couple of kilobytes at a time, as opposed to replacing the entire bundle. It's pretty effective. I assume it’s called a manifest.

I generally feel like I understand the process, but I just haven't played with it yet. If you go in and look through all of it, you can see all these little details. There's an endearing sense of nostalgia because that's how I learned the web. I learned the web by looking at how people did it before we came up with contraptions like minification—one of the absolute atrocities inflicted on the open web. Minification takes the premise that if we could just save 2% to 5% on the overhead, it’s worth destroying the web as a learning platform for new people. Absolutely not! We owe an enormous gratitude to the open web, and we ought to be proud to pay tribute by allowing view source.

View source requires this; you cannot do the view source if you're tree-shaking, bundling, or whatever. You can try to perhaps patch it on with some source mapping and whatnot, but then you’re piling more complexity on top of the complexity, and the tower will fall. The other thing I realized was the initial trick: what about security? Well, there is no security. Just in case anyone is actually serious, there is no security. Security through obscurity is, in fact, not security; it’s never been security. You should just assume that any person sufficiently motivated will understand every last thing about your application, no matter how much tree-shaking or whatever you do.

For me to even get interested in no build for real, it was just an infuriating annoyance being unable to compile a JavaScript project I had so carelessly left alone for about five minutes. None of the tools worked; everything was outdated. When I went to try to update it so I could compile it again, I literally couldn't figure it out. I spent half a day wrestling with webpacker at the time, and I did turn over the table, saying, "No, I made the integration for webpacker to Rails, and I cannot figure out how the [__] this works." There’s something deeply fundamentally broken in that model.

Before we tell the truth, I must say there was something so frustrating about spending half a day trying to figure out why charts V5 and charts V4 work and don’t work with Vite and ESM, and all those different things that you have to dance through. When someone makes an update, you don’t really realize what the hell has happened; it just doesn’t work anymore. I feel the pain deeply when someone says that, and I just hate it.

By the way, thank you very much, Crab, for that! Look at that! When you give five subs, you give me a bonus one. I appreciate the bonus one, Danish. The truth is, only the browser is forever. Only the browser will allow us to run code, markup, and styling that we made 30 years ago with no modification and no complaint. That is the beauty of the modern browser. It is a beast of complexity, and I would not wish it on my most mortal enemy to try to implement one from scratch today. However, the benefits we all reap as web developers from the fact that browsers have gotten this good, with such a commitment to backward compatibility, is incredible.

Someone might ask, "Is that actually true?" Well, you just have to realize how complex a browser actually is. Browsers are intensely complex. The amount of just...

=> 00:30:57

The true power of the web lies in its ability to run code from decades ago without missing a beat, proving that functionality always trumps style.

At that point, when you give five subs, you give me a bonus one. I appreciate the bonus one. Danish Jesus and the truth is, only the browser is forever. Only the browser will allow us to run code, markup, and styling that we made 30 years ago with no modification and no complaint. That is the beauty of the modern browser. It is a beast of complexity, and I would not wish it on my most mortal enemy to try to implement one from scratch today. However, the benefits we all reap as web developers from the fact that browsers have gotten this good, with such a commitment to backward compatibility, is incredible.

Someone might ask, "Is that actually true?" Well, you just have to realize how complex a browser actually is. Browsers are intensely complex. The amount of built-in features to make a browser not only functional but also capable of running your old code is astounding. Think about this: you can send down code that works from 15 years ago, and it still runs, despite everything moving on from it. If you've never worked with JavaScript, you're missing out on a good time—you know, you're missing out on the ability to hate your life.

Alright, I got to be back; I got to pee. I know we're only 13 minutes in, and I gotta pee. I didn't prepare properly. Don't worry, Chad, I peed on my hands; it's okay, everything's clean here. Here we go!

Incredible! The idea that you can design something in, let's say, 1995, and it still looks the same today is remarkable. Craigslist is a prime example. I don't think they have changed an iota of that design that launched back in 1995, and it still works. Not only does it still work, but it also thrives. That level of longevity when it comes to software development is something we should aspire to. I think that aspiration goes straight through the browser; it embodies the truth of the browser being the runtime of all of this code that we have. The more we can remove in terms of intermediaries between us and the browser, the better off we are. The more likely we are to have code that will run five minutes from now.

Now, I understand that Craigslist is not a beautiful website. People might say, "Ah, just return to BR," you know, brutalist fashion. The point is that you wrote something 30 years ago, and it still runs—that's the point. The point is that it still exists, it can still run, and you can still render it despite all of the good things happening in the change. The point is functionality; yes, it's the functionality of it, not the style, that's amazing.

Saying all that, another principle that we have straight out of the Rails Doctrine is the idea that we're pushing up a big tent. I have been incredibly excited about what we were able to do with Rails 7. I write all of the code we do at 37 Signals as no build. Every single application we made since Hey has been built without any form of JavaScript compilation and without any form of CSS pipelining. That's incredible!

Now, this approach doesn't have to be for everyone. The idea that I'm pushing forward connects to an overarching mission of creating a one-person framework with an onramp that is on the freaking floor. This allows someone to step on with very little prior knowledge about all it takes to create modern web applications. It is in service of that mission, as well as in service of my own enjoyment as a web programmer. But it's not a dictate. One of the things that have allowed Rails to thrive, from Hello World to IPO, is the flexibility of allowing folks to opt into the parts they want. Actually, that's not true; you opt into all of it, and you get to opt out of the parts that you'd rather do a different way. That's wonderful!

There are tons of applications built with everything from React to whatever else, and that's great. I love the path that we were able to take with Rails 7 to address that. So, okay, I didn't know that you can use React all you want; you can use any framework effectively and still use Rails on the back end. Well, that's nice! I assume server components are obviously kind of out unless you built a server component Rails app.

I'm curious about how these new meta frameworks work. They call them meta frameworks, but is it really a meta framework if it's just a framework that tells you what your client and server have to do? Is that really a meta framework? Are we just abusing the term "framework" these days? Is that what's happening here? Is that all that's happening at this point?

=> 00:35:13

Embrace complexity as a stepping stone to progress, but remember that true success lies in simplifying it.

I love the path that we were able to take with Rails 7 to address various challenges. One thing I didn't know is that you can use React or any framework effectively while still utilizing Rails on the back end. That's nice! However, I assume server components are kind of out of the picture unless you built a server component Rails app.

I'm curious about these new meta frameworks. They call them meta frameworks, but is it really a meta framework if it's just a framework that tells you what your client and server have to do? Are we just abusing the term "framework" these days? I think so, but it's an abusive terminology, of course. I'm also curious if this choice to move into these meta frameworks, like Svelte and Solid Start, is making it so that the non-JavaScript crowd cannot use these further items. What is that going to do to this audience as time goes on? If Rails can't update or if Go can't use it unless you build out the entire model itself, what happens next?

I had a job with Rails, and it was horrible. Rails has a low onboarding ramp but scales horribly. I had to learn all the intricacies, and the language itself starts fun. However, the untyped dynamic aspects become more and more of a pain as a project grows. Personally, I will always be a strict type, static typing kind of person. It's just my personal favorite. I don't really like TypeScript or dynamic languages in general; they're just not the place I want to be.

At the same time, I understand that some people thrive in that environment. I used to thrive in it too. I used to really like it, but I don't think TypeScript is good for me. Anytime you can just take something and go as "any," you kind of defeat the entirety of your type system underneath. I just don't like that experience; it's just not for me. I get it that some people love that, but just let me be me.

You can actually do that, yes. You literally can do that. How do you think JSON.parse works in TypeScript? It just works that way. That's why I enjoy the more Go side of things. I've kind of gone through it all; I started off in a typeless language, which means everything has types—they're just boxed types that the runtime interprets. Then I went to Java, and then I went back out again. It’s like I went from a dynamic-style language to a non-dynamic style language, back to a dynamic language, and then back to a more static side.

At this point, I've landed on the idea that I'd rather be slowed down enough to think about my types. Fundamentally, what excites me about this field, and why I am still here after 20 years, is that we are pushing forward towards a clearer mission. Someone just said something that made me angry: "Isn't TypeScript statically typed like Go?" No, it is not static typing. We can talk about this at another point, but not right now.

What gets me fired up is the bigger mission of the one-person framework and the invalidation of patterns where the context is no longer relevant. I tweeted this sentiment out a while back, and in honor of having Matts here at Raworth, I rewrote it as a haiku:

"Progress is our path, complexity builds the bridge, simplicity waits."

I've never seen someone clap for a haiku, but here we are in 2024—a new world, new time, new life. Let's go! What I like about this sentiment, whether in haiku form or not, is the idea that complexity is actually a necessary ingredient to progress, but it's not where we stop. We're not done by the time we've solved it; we're done by the time we've made it simple. That's a very different philosophy on when to stop and when to get excited, and one I try to embrace in everything going forward, including Rails 7. This is what we've essentially boiled down to the Rails 7 ethos.

=> 00:39:54

Progress thrives on complexity, but true success comes when we simplify it all.

A while back, I thought, in honor of the fact that we have Matts here at Raworth, I would rewrite it as a haiku: "Progress is our path; Complexity builds the bridge; Simplicity waits." I've never seen someone clap for a haiku, but here we are in 2024—New World, new time, new life. Let's go!

What I like about this sentiment, whether in human form or not, is the idea that complexity is actually a necessary ingredient to progress, but it's not where we stop. We’re not done by the time we've solved it; we’re done by the time we've made it simple. That’s a very different philosophy on when to stop and when to get excited, and one I try to embrace in everything going forward, including Relate.

This is essentially what we've boiled down the Rail 7 ethos to: "Rely on the browser." Give me a modern browser, and I can share in this bounty of goodness—all the progress that has happened, especially in the last three to four years. Hold on just one second. Someone said it has made it so much better and so much more fun to be a web developer without extraneous tools. We’re able to encapsulate all of that by saying this application is just for modern browsers. Now, we can’t do that for all applications; some applications have to support a longer tail of browsers. However, we can do it for a lot, and if you’re starting a new application today, you should absolutely do this.

Now, let's talk about the brain budget. I love the start of this perspective—not just to find the best patterns. The purpose is not just to seek simplicity for its own sake, although that is a gift in its own right. The purpose is to optimize for our limited monkey brains. They simply can’t fit that much. If we’re going to spend all of it learning the intricacies of some complicated build pipeline, there’s not room for that much else. What I want to make room for is all of it. I want to make room for the full-stack developer who can see an entire problem and an entire solution and keep it in their head for as long as possible.

Eventually, that will not be possible. I doubt that anyone can actually keep the five million lines of code that Shopify has in their main monolith in their head at the same time. However, the fact that someone was able to keep so much of it in their head for so long is what enabled us to get there. That’s the roundabout way sometimes that we end up in these discussions. People talk about, "Well, it is great for the beginning, but what are you going to do when you make billions of dollars in a day?"

What do you mean, "What are you going to do?" You’re going to do whatever the bleep it takes because it doesn’t matter. You have all the resources you need. If you are having troubles because you’re now making so much money and handling so many requests that you no longer really want to continue down the path of, say, using Ruby or JavaScript, you can just hire an entire team of excellent Go programmers and fix it. You don’t actually have to continue down that path because you now have everything you need to fix it.

I don’t dislike this approach, even though I do think that it has some level of danger in it. I can’t necessarily disagree with it. The danger, of course, is that when you decide to rewrite in a different language, it is not as simple as people make it sound. There’s a lot of implicitness in what you’re doing, and on top of that, it’s really hard to drive new features. So, you end up having a product that just stalls for a while—six months, one year—while you’re rewriting everything. You know, you can lose your edge.

It could be difficult. All the money in the world by then—that’s not the problem. The problem to optimize for is how do we get to the billions? That’s the path. It’s not like, "Oh, I’m going to be slightly inconvenienced once I have it." No, no, no. To me, the best way of looking at that problem is to consider the brain budget we have to compress all of these parts of the modern web development experience into small units that can fit next to each other, so we can fit all of them.

I got a good lesson in this recently because I picked up Vim again. You know what? Vim is one of those funny things that actually ends up taking a lot of your brain space, and you have to find a way to compress that so that you can fit, well, anything else—including the name of Jason here. I mean, I think Jason would be slightly offended if I started calling him Jarvis, my business partner. This idea that we have limited space means we have to utilize that space as well as possible.

=> 00:44:14

In a world where complexity reigns, mastering the art of simplification is the key to unlocking your potential.

In discussing the challenges of modern web development, I believe the best approach is to consider the brain budget we have. We need to compress all of these parts of the web development experience into small units that can fit next to each other, allowing us to utilize our limited space as effectively as possible. Recently, I had a good lesson in this when I picked up Vim again. It's interesting how Vim can occupy a significant amount of your brain space, and you must find a way to compress that knowledge to accommodate everything else.

For instance, I think my business partner, Jason, would be slightly offended if I started calling him Jarvis. This highlights the importance of utilizing our mental space wisely. Speaking of Vim, I must say that it’s my favorite part of this entire talk. However, I want to clarify that I don’t feel like I take up any space using Vim; it’s practically like my spinal cord doing all the work. I barely even think about it; it just happens.

Interestingly, when he mentions Vim, it almost sounds like Viagen, which is the name of my YouTube channel. It feels like he just gave me a shout-out on my programming YouTube channel! By compressing the information we have, we can avoid subdividing this industry into tiny slices of expertise. At a certain scale, that’s what we do, and it represents a billion-dollar problem. However, the real challenge is the 0 to 1 problem: how can we understand it all? That’s our mission, which is literally the headline of the website: compress the complexity of modern web apps. More importantly, we aim to facilitate the journey from Hello World to IPO.

Today, I want to focus on the space in between those two points, not just the Hello World or the IPO. For example, I’m considering whether to do Advent of Code in Ruby. If I were to pick a new language for that, I feel like I should do it in Elixir, just to appease Ryan Winchester. However, I might also stick with Ruby; it has metaprogramming, which sounds fun and intriguing. Can we all agree that metaprogramming in a dynamic language sounds like a blast?

I also want to take a moment to thank Ryan Winchester for subscribing and for the gifted subs. I appreciate everyone’s support, even if I’m not responding directly right now. We’re in the middle of a very long and deep experience. Thank you to Unhappy Engineer for the gifted subs as well.

Now, let’s get back to the topic at hand. With Rails 7, we have an incredible framework for creating Hello World applications. However, what we’re missing is the bridge to the IPO. The first step on that bridge is deployment—taking an application that runs on your machine and putting it on the worldwide web so that you can share it with everyone.

Over the past ten years, it seems that we’ve all turned into pink elephants, tied with a tiny rope of learned helplessness when it comes to deployment. The entire industry has cultivated a fear of touching a server, a fear of being responsible for a computer. I don’t blame them; I’m not sure if there’s any one person to point to as the cause of this mess.

=> 00:48:25

Don't let the fear of deployment hold you back; start small and scale up when you need to.

The first step on that bridge is deployment. It involves taking an application that's running on your machine and putting it on the worldwide web so that you can share it with everyone. However, what has happened over the past, let's say, 10 years, in my experience, is that we've sort of all turned into pink elephants tied with a tiny rope of learned helplessness when it comes to deployment. The entire industry has cultivated a fear of touching a server, a fear of being responsible for a computer.

I don't blame them; you know, I'm not sure whose fault it is. I don't know if there's any one person you can point to as the one who started all this mess. Personally, I put a lot of the blame on Tech conferences in general, specifically Tech conference-driven development. In this scenario, you learn about new technology, and then they say how it solves all these problems. Consequently, you bring in all those solutions into your company, which may be solving some really large, costly problem at a big company, but you just don't even have that problem.

I really feel like it's a grift mentality. I think it's just people sharing cool solutions to cool problems, but you just don't have that problem. For instance, most startups can run off a single VPS; they didn't actually need all those parts. Now, I get that as time goes on, you want more and more of these cool little things, and I do agree that those SNS and SQS are fun to play with. However, I am not convinced that everything needed it to begin with. You might have solved a problem that you don't even have.

In game development, we sometimes pivot an entire project because someone came home from a conference and revealed that a certain genre is going to be the hotness. I feel really bad about that because it's the same problem: you have an idea, you're doing something, and then someone goes off and says, "Here, let's do something else." You end up having to make a whole change, and it just feels like it sucks.

Hey, look at me; I'm subbing using Google. I appreciate that. Isn't that what being well-rounded has taught? It seems like learning as much related stuff—networks and servers—can help you better understand the landscape. Yes, being more well-rounded is good, but at the same time, it's also really nice to believe that you can handle any scale. The reality is that your six users don't actually end up putting much load on your system, but you've built it around this idea that you could have 100,000 users in a second. You just don't even realize that you never had that problem to begin with.

It's important to note that belief and capability are not the same thing. True, but one is the predecessor to the second. Would you rather build for scale or not and then need it? I think that's a false problem you're kind of creating. Very few people have a company that goes from no users to one million users overnight. That scenario is just not the average, or even the 1%, or the 0.1%, or the 0.01%. This is a very rare occurrence—maybe a couple of companies in the entire world experience this.

When you build for something like Hacker News, even then, you're talking about 100,000 users over the course of 24 hours. You have to remember that you can always take your one crappy machine that you're running off of your little VPS, and if things start scaling and you're not ready, you can go the other direction. Knowing that Hacker News means a whole bunch of people join, and maybe some of those people stay around, you could always just take that and throw it onto a 64-core machine for a little bit while you're trying to figure out what you need to do.

You can just do that. You don't actually have to have a kajillion machines running. Sometimes, you can just make your machine more powerful, and now you can serve 10x or even 100x more users. You don't have to worry about it until you're really trying to figure it out. Additionally, Fly.io also makes it pretty easy. You can use Fly.io or any of these other companies that are really popping up, which make it easy to have a singular machine, and then if you...

=> 00:52:23

Sometimes, all you need is one powerful machine to handle your growth instead of a complex server setup. Keep it simple and scale when necessary.

In the current landscape of technology, many developers are exploring various options for scaling their applications. It is important to consider that Hacker News attracts a significant number of users, and while some may stay, the influx can be managed effectively. One approach is to utilize a 64-core machine temporarily while determining the necessary steps for scaling. This method allows developers to enhance their machine's capabilities without needing an overwhelming number of servers. By upgrading to a more powerful machine, it becomes feasible to serve 10x or even 100x more users without immediate concern, until a more comprehensive scaling strategy is needed.

Services like Fly.io simplify the process of managing a singular machine, allowing users to scale as needed. This model is particularly appealing compared to serverless offerings because, with Fly.io, users still retain control over their machine. They can specify the number of CPUs and the amount of RAM, creating a straightforward experience. If the application demands it, developers can expand their setup into multiple machines, which is an exciting prospect.

When comparing Digital Ocean and Fly.io, the distinction is not entirely clear. The speaker admits to being vaguely familiar with Fly.io and suggests that both platforms are likely comparable in quality. However, they note that there is little incentive for larger providers like AWS to prioritize cost-effectiveness. While AWS can perform many of the same functions, it often requires considerable effort to navigate their user interface.

Reflecting on the broader implications of technology, the speaker humorously dons a "Dr. Evil hat," acknowledging the success of marketing that has convinced programmers that managing computers is overly complex. This sentiment highlights the disparity between the capabilities of developers and the perceived difficulty of handling technology. The metaphor of an elephant tied with a tiny rope illustrates how developers often underestimate their potential to overcome challenges.

Despite the complexities of platforms like AWS, which have built an impressive infrastructure to handle fluctuating demand, the reality for most developers is different. Many applications experience predictable traffic patterns, often fluctuating from zero to one user and back again. This means that the need for constant server management is not as prevalent as some might believe. The high costs associated with maintaining such infrastructure, both financially and in terms of complexity, can be likened to an insurance policy—a necessary but often excessive safeguard.

Ultimately, while AWS offers a robust solution for specific contexts, the speaker emphasizes that most developers do not operate in such environments. They caution against becoming a "pink elephant," forever immobilized by the fear of needing to scale, which can lead to unnecessary complexity and expense.

=> 00:56:52

Don't let the fear of complexity keep you chained to overpriced solutions; innovation is waiting for you to break free.

In the discussion about server management and cloud services, one participant raises a critical point regarding the testing user and the tendency for user numbers to drop back down to zero. They note that most of the time, there is no problem that requires constant racking of server monkeys behind an API. However, the price we pay for the insurance policy in case a problem does arise is exceptionally high—not just in monetary terms, but also in terms of complexity.

The phrase "insurance policy" resonates deeply, as it encapsulates the ongoing anxiety about server management. The participant acknowledges that while they believe AWS is a business and that business is great, they also recognize that businesses have incentives. Specifically, the incentive for AWS is to keep users a pink elephant forever, instilling a fear of managing their own servers.

Despite these concerns, the participant expresses a nuanced view, stating, "I actually don't think that using AWS is all that bad." They highlight that one can simply grab an EC2 instance, which may not always be significantly more expensive than other options. They point out that while utilizing all AWS services can be costly, one can also opt for a singular instance. S3 is super convenient and relatively inexpensive for what it offers, leading to the question of what exactly is being critiqued in the broader discussion.

The conversation shifts to the competitive landscape of cloud services. The participant argues against the notion that servers are so difficult that AWS should maintain 40% margins, contrasting this with Dell, which has a 5% margin. This discrepancy suggests a failed market that lacks competition. They further elaborate that using Ruby comes with its own costs, and there is a prevalent trade-off between developer experience and computational experience.

In light of these challenges, the participant praises Hoku as one of the greatest breakthroughs in developer economics over their 20-year career. They reminisce about the launch of Hoku in 2007, noting that at the time, most of us even had a broad conception of what containers were. The ability to reduce deployment to a simple git push was revolutionary, and it is remarkable that it took over a decade for others to catch on.

Another participant mentions that Fly is the new better Heroku, to which the first participant agrees. They reflect on their experience starting their first company in 2010, marveling at how Heroku felt like magic compared to the manual server management they were accustomed to. They describe the complexity of managing a server with a Squeal server and Apache, contrasting it with the seamless experience Heroku provided.

Heroku, they argue, deserves endless accolades for its achievements and for helping countless Rails developers transition from hello world to the LMA. They emphasize that it has been 17 years since Heroku's inception, which is astonishing, especially considering that Heroku is older than some people in this chat.

The participant concludes by highlighting the changing context over those 17 years. They mention the current pricing for Heroku's performance tiers, noting that you can buy the luxurious One Core two threads, 2.5 GB of RAM for the small fee of $250 a month. They reflect on how this pricing might have seemed appealing back in 2012, illustrating the evolving landscape of cloud services and the ongoing challenges developers face.

=> 01:01:12

In a world where tech prices soar, sometimes the best deal is just a click away.

For what they've achieved in helping a significant number of Rails developers transition from the "hello world" to the LMA, it is evident that this is an incredible achievement. Remarkably, this was 17 years ago, which is mind-blowing in its own right. It's only now that we are starting to think, you know what, maybe we should catch up.

Heroku is older than some people in this chat, and the problem with that is, in part, that the context has changed over these 17 years. Here’s our Heroku performance: you can buy the luxurious One Core, two threads, and 2.5 GB of RAM for the small fee of $250 a month. I'm sure that sounded pretty good in 2012; that was a good deal. However, I actually can't even tell if that was a good deal or not.

By the way, when someone says they're below 13, we have to ban them. So, if you were stupid enough to say you're 12, just know that you are permanently banned. I can't unban you, just so you know. When you send a response saying, "Hey, it was just a joke, bro," like I actually can't unban you.

Now, just to clarify, I’m going to ban you as well because I don't know the exact rule around it, so you are also permanently banned. I'm just not going to let you back in ever, for any reason. So, I'm just letting you know that when you say these dumb things, like "I don't know the answer," I just don't know how you're so stupid. Please, just stop being stupid.

On a lighter note, he turns 14 next year. I say, dude, to protect Twitch chat for a little bit, can we just put it in emote mode for just a moment? Just to protect them for a moment because they're OB. Oh dude, can we pour one out for Bible Thump?

That’s preposterous! That is ridiculous and offensive. Here’s a hobby box I signed up for a couple of weeks ago from Hetzner, where you buy the raw hardware and get 48 cores, 96 threads, and 256 GB of RAM. Isn't this the exact same computer as a $4,000-plus dollar computer? You could rent it out for practically a year and a half before you paid for it.

I know there's some serious European math going on here that I’m actually confused about. Is this shared? I would assume it's not shared. Dude, imagine renting out 48 cores as shared; there ain't no way that’s happening.

At $220 a month, what is the difference between those two things? Heroku has nice software. I make software too; I think I could make some nice software. I would rather make some nice software than pay 100 times more for my RAM or 50 times more for my compute. If they also throw in two terabytes of NVMe RAID storage, that’s a pretty good deal.

Honestly, I’m having a hard time trying to think of why I’d ever buy a laptop again when I could just rent out the newest hardware. This is kind of crazy. The Joker is, if we can convince people that they are basically incapable of touching a computer, we can charge them 100x because what are they going to do? Touch Linux?

I understand that it would be really awful to actually do that, having to constantly SSH into everything. I get it; I'm on your team. Dude, imagine touching Linux. Okay, Windows users are technically in shambles right now, much of developer tech, and I don't like it.

This is not my meme. I don't know if DX sent him this, but I will say this much: Vercel hasn’t been able to catch a break since the Lex Friedman interview. It feels like they have just been hit continuously; it’s just not stopping. I think this is Dax, though; it’s a Fire Ship meme. Is it a Fire Ship meme? I can never tell.

In conclusion, they have just kept getting hit, and it just keeps going lower and lower. But no wonder there is a growing...

=> 01:05:44

The tech industry thrives on insecurity, but the real opportunity lies in creating value without the endless premium.

Technically, the situation is in shambles right now for much of developer tech, and I don't like it. This is not my meme. I don't know if DX sent him this, but I will say this much: Versell hasn't been able to catch a break since the Lex Friedman interview. It feels like they have just been hit repeatedly; it just keeps going lower and lower.

I think this is Dax, though; it's a Fire Ship meme. Is it a Fire Ship meme? I can never tell. This really looks like Dax or Fire Ship. They have just kept getting hit, and it feels like it won't stop. However, there is a growing industry of people who realize, "Holy [__], I can get 100x returns, and I don't even have to buy the computers. I just rent them from Amazon and then rent them to you for 100 times what I pay." What a business model!

Agreed. You know what? That's what the VCs are saying too; this is a growth opportunity. The best part is that Versell makes money on so many parts of their product that they're actually able to offer out a huge portion of their codebase for free. It's just like, "Oh, you want to use it for a little while? You can just use it for free!" Just imagine how amazing that is.

Since the Levels IO interview, it feels like every single move they’ve been making has just been getting crushed. The insecurity of developers is a mass market; let's tap into that, and that throttle has been pushed all the way to the floor. I don't like it. I like when businesses identify something new, when investment flows into that idea, and when new concepts are developed. But at some point, I'm not going to pay the premium for that forever.

Now, I hate with a moral passion software patents; I think they're absolutely stupid and corrosive. I hold that idea in my head next to the idea of liking medical patents. I actually feel like I'm about to agree with this entire take, but software patents truly are such a problem. The fact that you can do that genuinely needs to be destroyed.

I actually think it's reasonable that the kind of drugs we bring to market should be protected. You can't possibly do your own; it's dangerous. You can only use stuff like Clerk. By the way, I have a good friend who just rolled his own authentication, and he said he was shocked at how not hard it was. He thought rolling your own authentication was an impossible activity that would take forever, but then he tried it out and realized, "Oh, I see where all the danger is. I can definitely see why you want to be very careful doing this, but man, this was not nearly as complicated as I thought it would be."

He even made some of his own JWTs; they're not even all that hard. You just take a payload and hash it such that you can hash it again on the client side to tell if the server's stuff has been touched or not. It's just like, "Yeah, I know it's crazy, right?" It's not that crazy. I do agree, generally speaking, you should probably avoid hand-rolling your own authentication and just use at least OAuth or something that already exists. Just say, "Hey, just sign in with Google, Twitch, GitHub, Yahoo Mail, or Hotmail."

It's just funny; drug testing requires multiple trials, and that is expensive—about a billion dollars. That requires someone being able to recoup that billion dollars for us to get wonder drugs like Usek, which now represents something like 20% of the Danish economy. So, thank you very much for all the perhaps slightly plus-sized Americans who are funding the Danish welfare state; that is something I'm very grateful for.

Stop, bro; he's dead. Quit it! Not only did he call me that, but he also made fun of like a fourth of the world in a single swing. However, I also think that patents should have an expiration date. In the medical world, that expiration date is 20 years. In 20 years, your patent will be up. I thought it was seven; is it different in various countries? I look at that and go, "That's actually not a bad model.

=> 01:10:04

The future of healthcare innovation lies in making life-saving drugs accessible and affordable through generics and open-source solutions, not in letting patents create monopolies.

The discussion begins with the notion of recouping a billion dollars to obtain wonder drugs like usek, which now represents approximately 20% of the Danish economy. The speaker expresses gratitude towards “perhaps slightly plus-sized Americans” who are funding the Danish welfare state.

However, the conversation takes a turn when someone makes a comment that provokes a reaction, leading to a remark about a person who has passed away. The speaker reflects on how this individual made fun of a significant portion of the world in a single statement. They believe that there should be an expiration date in the medical world, suggesting that 20 years is a reasonable timeframe for patents. They initially thought the duration was seven years, but upon further consideration, they acknowledge that it varies by country.

The speaker appreciates the commercialization efforts of Hoku, which successfully navigated the initial foray into developer economics. They argue that the industry is overdue for generics and that the cost of drugs, which can be exorbitant, should be significantly lower. They assert that a drug or cure should not cost $250 for a pathetic amount of compute but should be 100 times cheaper. This reduction in cost could be achieved through generics and open source solutions.

The speaker emphasizes that SST (presumably referring to a technology or framework) makes many things accessible without excessive markups, which they find impressive. They admit to having limited knowledge about SST but recognize it as a well-designed product that runs terminal. They explain that they have developed a Go front end with a JavaScript back end, humorously referring to their setup as the “mullet stack.”

They express optimism about the potential to save the industry from itself, suggesting that if an opportunity is egregious enough, someone will inevitably step in to exploit it. They reference a notorious figure, Martin Shkreli, who is known for dramatically raising the price of certain drugs, and acknowledge the dangers associated with patents. While they understand the need for protection due to the high costs of drug development, they also recognize that it allows for the existence of “horrible people” who take advantage of the system.

The speaker struggles with the complexities of the issue, feeling conflicted about the right answer. They express a desire to “kick right in the shin” those who exploit the system, although they note that the situation is different for the COVID vaccine, which was expedited through testing in production.

The conversation shifts to the mission of Rails, emphasizing that it aims to create a framework that does not require payment to a commercial vendor to go into production. The goal is to allow users to deploy applications on any hardware of their choice, whether it be a cloud VM, their own computer, or even a Raspberry Pi. The speaker insists that the main path should enable users to run their applications independently, without being tied to someone else's hardware. They critique frameworks that are designed in a way that makes it difficult to operate without their complete setup, referencing the ongoing struggle between Open Next and Next.js. They express frustration that the default running path often favors third-party hardware rather than empowering users to run their applications themselves.

=> 01:14:45

Don't let server phobia hold you back; embrace Linux and conquer your fears one step at a time.

Frameworks that you should use are essential in today's development landscape. However, it can be frustrating when frameworks are designed in such a way that you can't or not very easily use them without their entire setup. This issue is exemplified in the ongoing debate between Open Next and Next.js. Open Next is continuously trying to figure out how to make Next.js runnable, which highlights a significant concern: the default running path is often not for developers to run themselves but rather for them to run it on someone else's hardware.

This brings us to a larger problem that the cloud has cleverly infected us with: server phobia. This is the idea that servers are "icky" and that many developers would prefer to avoid them altogether, seeking relief from that responsibility. However, it's crucial not to buy into that premise. There is a cure for server phobia, and that cure is Linux. Not only does Linux run all of our servers, but it can also run on your computer. I encourage you to try it, whether you want to run it full-time or just experiment with it. This approach is akin to cognitive behavioral therapy—one little exposure at a time.

I have a framework running right here that you can come touch afterward; it will not bite you, even though it runs Linux. It's fascinating how we transitioned from a discussion about Rails to advocating for the use of Linux as a way to overcome the fear of servers. To be completely fair, I remember the first time I launched my own server. I had a LAMP stack; I was a "lamp boy." I tossed it up there with a combination of Linux, Apache, MySQL, and PHP. I was "lamping" hard. I even used ZAMP on Windows, developing everything with NetBeans.

When I first logged into my server, I was scared. I feared I would take down everything or ruin my setup. There was no Docker back then, and rerunning your product was quite the effort. For a long time, I developed a fear of servers before I eventually got over it. I believe that everyone should try something new, even if it means stepping out of their comfort zone.

To that end, I created my favorite Linux environment, which I am sharing with you: AMAC coup. This project aims to take that scary Linux machine and transform it into a comfortable, productive, and great-looking setup that you can jump right into and use. I love that we are discussing Rails while also exploring the great discoveries of Linux. One of the things you might discover is a new editor that feels just right for you.

You might even appreciate a new computer. For 20 years, I was not in the market for a computer that didn't have a little apple on the front of it. However, I eventually came out of that haze and realized that other people were making cool stuff too. For me, Framework is a great example of that. I am currently running it on my machine, and it works beautifully with AMAC coup.

Now, you might be wondering about the System76 framework. Is it the way to go? Do you need to switch over to Framework? I have never tried it, but I love the idea of right to repair. However, can it actually stay that way? Perhaps I might have to give it a try for my next computer.

It's important to note that the hacker will get you no matter what you use. I hate to tell you this, but your Linux machine already has like 18 backdoors, of which 17 are from the NSA, and we are just discovering them slowly as we go. That's all there is to it.

=> 01:18:57

It's more fun to be competent; knowing how things work empowers you to create, innovate, and solve problems effectively.

System 76 is a framework that many people consider the way to go. I need to switch over to Framework; I've never tried it, but I love this idea of right to repair. However, I wonder if it can actually stay that way. I might have to give it a try; maybe my next one will be a Framework.

The hacker is going to get me, that's the pink elephant talking. You don't have to listen to the Pink Elephant; you can graduate from Pink Elephant Hood into something else. To be completely fair, the hacker is going to get you no matter what you use. I hate to tell you this, but your Linux machine already has like 18 back doors, of which 17 are from the NSA, and we're just discovering them slowly as we go. That's all that's actually already happening; don't worry, you're already completely compromised. I wouldn't even worry about it.

Cloudfront and NSA front, right? Or Cloudflare? Sorry, Cloudflare; we might as well just call them Cloudfront at this point. We all know what is actually happening here. Okay, Tor networks are just the CIA, and Cloudflare is just the NSA—this is all just the way it is. Oh wow, my business keeps losing money yet it keeps operating; it's crazy. We only just handle a third of the world's traffic; it's weird.

And that's something else; it's also not a [__] dog. This is not the dog you're going to be. No, this is you on day one. This was me on day one of Linux; this was me on day 21 of Linux, but it did not last forever because eventually, you'll get it. Eventually, you'll level up, and that's what we're aspiring to, especially when it comes to security.

This is one of the things I get so frustrated about: like, hey, here's a cheat sheet for setting up a secure server. Put an SSH key on it, make it such that the SSH key is the only way you can authenticate access to that server, and start the very nicely UI for the firewall. You're done! I mean, not quite, but that's like 90% of it. 90% of the security of a Linux box is just like [__] lock it; don't leave the door open. If the door is locked, they can go up and jiggle the handle, but they won't get in.

All of this is just an incarnation of the fact that it's more fun to be competent. It's more fun to know what the [__] is going on; it's more fun to know Linux because that's where your applications live. It is more fun to be competent. I love that phrase; it's more fun to be competent is my favorite. After DHH said that on the TopShelf Podcast, it has been the best distillation of how I feel.

What is the least fun part about developing? It is developing when you have to copy and paste a solution. The reason is that you couldn't create it yourself; you just didn't know what you were doing. You had to go search, look, and reason about someone else's code. You had to just kind of think, "Oh gosh, is this actually it or is this not it? I don't know; I hope this is it. This looks right; I hope this is right."

You know what is way better? Knowing something's right, knowing the API, knowing the language, knowing how it works, and actually building something because this is the way you're doing it. It feels good; that feels good. It feels right.

What if you don't have time to do it? You can't know all things; it's a trade-off. It's always going to be a trade-off. You need to figure out what is the right thing for you to learn, what is the right thing you need to be an expert in, and what is the right thing to defer to somebody else. And it's okay; that's part of competence.

Competence is wisdom, the ability to know which problems to solve. You cannot solve all problems. You can't go from machine code to the operating system to the compiler to your program running to writing your own HTTP request. You have to offload some of that somewhere. I'm not going to develop my own CPU; I'm not going to develop my own operating system; I'm not going to develop my own compiler; I'm not going to develop my own HTTP algorithm.

Actually, I did develop the WebSocket algorithm for Netflix, and it's used by a lot of people and works perfectly fine. But you don't also need to be that person; you don't actually need to write that. You don't have to; there's already a bunch of stuff already there for you.

Right now, I know you might be feeling like Woody, but we're going to go to infinity and beyond, and that's actually the reason I really love 8.

=> 01:22:49

You don't need to reinvent the wheel; just build on what's already out there and level up your skills along the way.

In the world of software development, there are numerous layers involved, from code to the operating system, to the compiler, and finally to your program running. When it comes to tasks like writing your own HTTP request, it's important to recognize that you don't have to reinvent the wheel. For instance, I'm not going to develop my own CPU, operating system, or compiler. While I did develop the websocket algorithm for Netflix, which is widely used and functions perfectly, you don't need to be that person. There is already a plethora of tools and frameworks available for you to utilize.

You might be feeling overwhelmed right now, but remember, we're going to go to infinity and beyond. This is actually why I love the number eight so much; when you tilt it over, it symbolizes infinity. So, let's dive into Rails 8 and explore some of its wonderful features that serve our mission.

Speaking of introductions, a colleague recently delivered a 37-minute intro that was truly impressive, especially since he did it live as a talk. It was a fantastic presentation, showcasing his skills as a certified yapper. Now, let's discuss the first feature of Rails 8, which I am genuinely excited about.

However, before we delve into that, let me clarify something important. Rails is not going to ship with Device or a black box of security. Instead, it will guide you on the path to understanding what’s really going on. We will implement authentication through generation, which means you will generate the code yourself. This approach ensures that you actually look at it, understand it, and realize that authenticating a user is not something to be taken lightly or outsourced.

It's worth noting that copying is a good activity; in fact, it shows that Phoenix did the right thing by being a source of inspiration. You should definitely understand the basics of secure passwords, as it’s not that difficult to learn. Essentially, the process involves taking a password, applying a nice hashing algorithm that is complex enough to be safe, and using a secret salt on your server. You then combine these elements and store the hash.

Now, can the salt be public? While some might argue that it can be, I would advise against it. Using MD5 is not a good idea; it’s considered a joke in the security community. Back in the day, MD5 was seen as a reliable method, but today, it's known that there are ways to create collisions, which defeats the purpose of salting. You definitely don’t want to store passwords in plain text; that would be reckless.

Instead, you can regenerate passwords and achieve a 90% authentication system. The files you will encounter are beautifully crafted; I have carefully and lovingly handcrafted them for you. These are artisan templates that I created with great care, providing you with an excellent starting point to work from. This authentication system is essentially an extraction from our own applications, showcasing how we write authentication systems without all the extraneous elements.

Ultimately, our goal is to help you level up. On day one, you might feel like a novice, but rest assured, you won't remain in that position forever. We are here to teach you, and after spending some time with Rails, you will gain a solid understanding of the framework. This is a fantastic outcome for anyone looking to grow their skills in software development.

Lastly, I want to mention something I'm particularly proud of: Prop Shaft. While it may not directly relate to the overall topic, it is one of those side dividends that adds value to our work.

=> 01:27:14

Level up your skills and simplify your code—embrace the modern web without the baggage of the past.

In this presentation, we discuss how to write authentication systems effectively without the extraneous complexities often associated with them. Our goal is to help you level up your skills. On day one, you may feel like a novice, but rest assured, you're not going to stay that way forever. We are committed to teaching you valuable skills, and after spending some time working with Rails, you will understand the true potential of using this framework. That is a great outcome, honestly.

Another topic I am particularly proud of is Prop Shaft. This innovation is a side benefit of simplification that emerged when we embraced the modern stack of HTTP/2 in Rails 7. We recognized that the asset pipeline, which had been in place since 2009, was outdated and overly complicated. Prop Shaft represents a clean slate, allowing us to address the current context without the burden of old baggage. This approach is not only beautiful but also effective, and I take pride in having contributed to its development.

As a brief interlude, I need to take a moment to hydrate, as my throat is feeling strained. On a lighter note, I have a funny story: this morning, while using the bathroom, my cat jumped up between my legs to see what was happening. Unfortunately, this led to an unexpected incident where I accidentally sprayed my cat. It was quite the surprise, but sometimes these things happen!

Returning to Prop Shaft, it serves as a streamlined asset pipeline. While you’re not expected to read every line of code, I encourage you to explore the manifest bundle in Prop Shaft after starting a new project. I guarantee you will find it understandable, unlike the complexities often associated with Sprockets. Prop Shaft is built on the core idea that, after leveraging the benefits of modern browsers, we only need a load path and to digest assets for long-term caching. This simplicity allows the system to be small, easy to comprehend, and minimizes potential issues.

What does this mean practically? It means that two-space tabs are for psychopaths, and we create a manifest with a collection of URLs. This functionality is straightforward, and while Prop Shaft is minimalistic, it aligns with the broader vision of modern web applications. Historically, these applications required multiple data storage solutions, such as systems for running queues, caching, and routing.

To clarify, Prop Shaft must take in all these assets, which is likely how unique identifiers (UUIDs) are attached to every filename, facilitating the creation of manifests. When a file changes, the system loads the entire file, performs a checksum (perhaps using an MD5 hash), and updates the versioning accordingly. This process ensures that while you may still reference foo.js, the actual file served could be something like foo.js-<hexadecimal-digits>.

Furthermore, we can consolidate various database operations into a single database system. Today's databases are so efficient that we often do not need to rely on RAM for most operations, and we should capitalize on this capability. In Rails, we are introducing a trifecta of database-backed adapters known as Solid. This advancement is part of our ongoing commitment to improving the framework and enhancing your development experience.

=> 01:31:31

SQLite is a game changer; it turns databases into simple files, making development faster and easier than ever.

This is just me thinking out loud. It must load the whole file up, do some sort of stupid MD5 hash or whatever it is on top of it, just to create a quick checksum, toss it on front, and say, "Okay, this is the new version of the file." Then you're still requiring foo.js, but on the other side, it's actually fu.js—some big shop, some set of hexadecimal digits, whatever it is.

Okay, E-tag, okay, webset updates. Is this the part where you mentioned SQLite? Because we can collapse all of that into one database or at least one database system. The database today is so fast that we do not need RAM for most operations, and we should take full advantage of that. In Rails, we are introducing a trifecta of database-backed adapters called Solid.

We have Solid Cable for backing WebSocket communication through databases, Solid Cache for storing cached data in the database, and Solid Queue for running jobs on that. It all runs from the One Ring—one database system, one thing to learn, one thing to operate. Even better than that, and it was not even in the design, but it propped up along the way: SQLite.

Let's go! SQLite is actually impressively good. The amount of databases you can create and drop, and new ones, is just amazing. People have been sleeping on SQLite, and I don't think they need to be. Ryan, Solid JS, is crying also right now that there's a new solid in town. It has allowed us to even take the system out. I sleep with SQLite—there's no longer a process to operate, just a collection of files that you use directly.

This is an incredible service to our mission of making it easier to go from "Hello World" to something that's online. You don't even have to know how to set up a database; it is just a file in your file system. There are some things you have to figure out, like writing to the same place and making sure you don't have those database lock errors and how to retry and stuff like that. There’s definitely a little bit more, yet I still ran into these database write errors even with WAL (Write-Ahead Logging). So, you do have to do a little bit of extra work on top of it, but nonetheless, it is incredible.

The best part about SQLite, which people are just absolutely missing, is that you can literally take the state that has happened, save it, and then start from that state anytime you want to. It's just a file! Remember, SQLite is just a file.

So, that ends up looking a little bit like this: when you start a new Rails 8 application, you will actually get four database files for SQLite—one for the primary database where all your domain models live, one for caching, one for queuing, and one for cable. You don't even have to open this file to go live; you don't even have to know anything about how this is all configured because, through the wonders of SQLite, we don't have to.

As I mentioned, the first is Solid Cable. Solid Cable is one of those extractions that came in about two weeks ago when I was preparing this talk. I was going through my demo and saw that I still needed Redis. I was like, "We're so close! We're so close to taking Redis and putting it over in the optional bucket, but we're not quite there yet." We needed something for Action Cable. What do we do? Thankfully, Nick Pesa implemented Solid Cable as a database-backed adapter for Action Cable, which made my keynote so much easier. So, thank you, Nick, for improving the flow of my keynote.

This chat knows a lot about Solid Cable, so I don't really understand this database-backed WebSocket connection thing. Is this just for creating some sort of ephemeral chats and then having those chats stick around long enough that if you refresh, you can see it again? I don't really understand what it is, but I understood all the words individually; I just didn't understand them all put together that way.

Why reinvent the wheel when Redis is already solving this problem? I mean, Pque Light also solves a lot of this problem right now. What blew my mind about Solid Cable is just how fast SQLite is, especially on the same computer. It is incredibly competitive with a system that operates entirely in RAM, like Redis. This Solid Cable adapter gets within 50% of the performance of a purely RAM-based Redis setup, and it's writing to a freaking file! That's incredible.

That's one of those aha moments where you realize that this would not have been possible in 2009. NVMe drives have jumped significantly since then.

=> 01:35:36

Innovation in tech isn't just about speed; it's about how we leverage new tools to redefine what's possible, especially when it comes to performance and privacy.

In the ongoing discussion about technology and its applications, a recurring theme emerges: why reinvent the wheel when Redis is already solving this problem? This sentiment reflects a broader confusion about the complexities of various systems. While the individual words make sense, the overall message can sometimes be unclear.

One of the most impressive aspects of Solid Cable is its speed, particularly when compared to other systems. For instance, SQLite is incredibly fast, especially on the same computer. It competes closely with systems that operate entirely in RAM, like Redis. The Solid Cable adapter achieves within 50% of the performance of a purely RAM-based Redis, even while writing to a file. This is a remarkable achievement, especially considering the technological advancements since 2009. The significant improvements in NVMe drives, which have increased by two orders of magnitude, have made this possible.

The advent of solid-state drives has transformed the landscape of data storage and access. However, whether one chooses to use these technologies in production may depend on the specific needs for Redis or other systems. The goal is to simplify the process to the point where users don’t even need to think about the underlying complexities. It’s important to note that you don't have to sync with every single write; this flexibility is a crucial feature.

Looking ahead, there are many performance improvements and developments expected for SQLite over the next two years, which will likely help close the performance gap. As users become more familiar with these technologies, they will find themselves navigating the systems with ease.

Another significant development is the Solid Cache, which originated from a direct need within Basecamp's setup. Previously, the company relied on a large caching system built in Redis. In 2015, there was a notable moment when a substantial amount of RAM was laid out for their boxes—15 terabytes or more. Today, Basecamp utilizes Solid Cache in production, storing 10 terabytes of caching for 60 days. This extended retention period has drastically improved response times, with a 96% hit ratio, which is quite impressive.

The impact of this caching strategy is evident in the performance metrics. For instance, there was a noticeable improvement in request times, dropping from 400 milliseconds on the P95 to around 200 milliseconds afterward. This improvement is a direct result of maintaining caches for a longer duration. However, there were also challenges, such as a minor bug that occurred during implementation.

The conversation also touches on privacy concerns, particularly regarding email services like Hey. A question posed by a spouse about whether employees could read personal emails highlights the importance of encryption. Solid Cache supports encryption, built on top of Active Record, which was designed with privacy in mind. This feature allows for better protection of sensitive personal data during routine operations, marking a significant advancement in privacy practices.

Retention policies are another critical aspect of data management. When a user deletes their account on a service like Hey, the expectation is that their data is permanently removed. However, the reality at many companies is that a simple Boolean flag is set to indicate deletion, but the data remains accessible. This raises important questions about data privacy and the handling of user information by larger companies.

=> 01:40:04

When you hit delete, make sure your data really disappears—because "deleted" shouldn't just mean "hidden.

In discussing the topic of programmers and sensitive personal data, it is important to note that there has been a significant improvement in privacy measures. I hope this is something that more people will adopt.

Retention policies are closely related to this issue. For instance, if you sign up for a service like Hey, use it for a while, and then decide to delete your account, you may wonder what happens to your data. Generally, when you delete your account with most companies, a little Boolean is set that indicates deletion is true. However, the reality is that your data is not actually deleted; it remains accessible to the company. I find this concerning because when I say delete, I want to know that at some point, at least, it is truly gone.

In contrast, Hey backs up its deletion warranty with a specific timeframe: if you delete your data, it will be removed from their logs, database, and cache within 60 days. This retention policy is supported by a robust infrastructure, which includes a substantial cache of 10 terabytes. However, they only allow data to exist for a maximum of 60 days, adhering to their retention policy.

Another appealing aspect of the solid cache is that it is built on the rigor of Active Record, which provides the flexibility to expand storage beyond the initial 10 terabytes if necessary. Although I have never personally used Active Record, I have heard numerous people praise it, describing it as the best due to its capabilities. It is not limited to a single machine, which enhances its utility.

About 18 months ago, when we were starting a new application, I realized that I did not want to deal with multiple gems just to process jobs. Many of these gems were private forks, which made the situation seem broken. Therefore, we decided to take a clean sheet of paper approach and build a new Active Job backend that would be high-performance and capable of handling all the jobs we needed to push through the system. This backend would support the three major databases: PostgreSQL, SQLite, and MongoDB, ensuring that it would be functional for everyone, including those using MySQL and Oracle.

The system we developed can operate in two ways. It can run in its default mode, where a single process operates, and solid Q attaches to Puma. This is the default setup. Alternatively, it can run as a separate set of job hosts, which is what most applications will do once they reach a certain scale. In this case, you would run bin jobs to start the supervisor, and all jobs would run for you, backed by a database that allows for interrogation if something goes wrong.

Building out a jobs platform is actually a fun problem. My last project at Netflix involved helping to improve a testing environment, which was essentially a job system where device registration and tasks needed to be combined to produce output. I found this to be a satisfying challenge. Part of me felt a bit sad leaving Netflix without seeing the project through, as there were many enjoyable aspects to it.

I have always found this problem space to be incredibly interesting, and I am pleased that we developed all the necessary tools to tune systems in high-velocity environments. The platform can be initiated with various configuration files tailored to specific parts of an application, and it even includes recurring jobs, which was a challenge we faced while migrating applications to the cloud. This new approach offers a better solution that operates fully within your Rails application and can initiate any job.

=> 01:44:24

Embrace simplicity in tech: fewer dependencies lead to smoother operations and greater efficiency.

I was a little bit sad leaving Netflix because I didn't get to see the thing all the way through; there were just so many fun parts about it. Oh well, I've always thought this problem space is super interesting. I'm ever so pleased that we ended up coming up with all these stals that you needed to expose to tune things in high-velocity environments. You can start it with all sorts of different configuration files for specific parts of your application. It even has recurring jobs built in, which was one of those challenges we faced when we were moving applications to the cloud, or into containers, I should say, and trying to figure out what to do with Kon.

This is a better Kon that runs fully inside your Rails application and can start any job. This is actually what our in production looks like. At least, I thought, DHH was the one that kind of coined the term. Sorry, something's going on right here, and I don't know what's happening. There’s some noise; either my cats are causing some real problems or not. I thought DHH was the one that championed the idea of convention over configuration, but for the last few slides, it's been quite a bit of configuration. Is that bad? That's how I felt recently too.

At scale, you have to configure. I mean, I don't know how you wouldn't do that, right? You don't understand that this configuration has conventions to it. Calm down right now, buddy. Two-thirds of all the different Quant jobs that we set up, and this entire system is doing 20 million jobs per day just on Hay. It's a good amount of jobs; it's incredible. We have another 80 million jobs to run on Basecamp and some of our other systems. We're going to bring it all onto Solid Q to run about 100 million jobs a day.

It works; it's good; it's easier. It does not require seven gems, and you can kick Redis out of your stack when you shift. Nice! I do like the idea; I know I just interrupted you. I do love the idea that he is pushing towards taking things out. There is something really nice if you just have SQLite; like, there’s nothing else—like, that’s it. It’s just SQLite; you use it all over. To me, that’s really nice as opposed to having to have all these different types of services for every last little item.

I'm not saying that, obviously, Redis—I mean, at least by the numbers, by the performance testing he did, is better. But I like this idea of having just less dependencies; you only have to consider one thing: kick Redis out of your stack when you shift. The other idea of getting rid of all the dependencies with Rails 8 is the idea of getting rid of index and other forms of proxies—other forms of things you have to put in front of your application before it's ready to face the internet.

The mission for Rails 8 was that the Rails 8 container image that comes out of the default setup should be directly exposable to the internet. It should be fast, it should be secure, it should be easy to use, and it should require no expertise. Thruster brings half of this as one part of the proxy. It brings accent file acceleration; if you're sending a large file, you're not going to tie up your Puma process to do so. It does cache control caching of anything you send public to or otherwise, so again, Puma doesn't have to deal with it. It also does Gzip compression and eventually will do Brotli as well.

It is installed by default in our lovely default Docker image down here on the exposed 80 or just below the exposed. You run Thruster right in front of your Puma, and you just get it. Do you need to have a prop shaft in between your Puma and your Thruster? Like, how does this work? I'm a little confused on that one. Where does the prop shaft come into place, and is it the thing you're thrusting? I'm a little confused right now, but I'm sure I'll get all this stuff.

Thruster is entirely no config by default; it is just one command you run in front of Puma, and you get all the good stuff. It's pretty damn nice. It's also written in Go; Go is a very nice language for writing proxies. By the way, that's like the next thing I want to write on this stream: a proxy. Now that we just got done finishing up with Vim Arcade, which has been running and has done a fairly good job of actually creating a bunch of servers and closing and not closing and running and all the fun stuff, I'm actually very curious to see this thing go on. I believe I've made it all the way to the end and million proc a million.

=> 01:48:24

Simplifying deployment is the key to unleashing your app's potential—no config, just run and go.

Right now, I'm sure I'll get all this stuff set up. This entirely no config by default solution is just one command you run in front of Puma, and you get all the good stuff. It's pretty damn nice! It's also written in Go, which is a very nice language for writing proxies. By the way, that's like the next thing I want to write on this stream: a proxy. Now that we just finished up with Vim Arcade, which has been running and has done a fairly good job of actually creating a bunch of servers, closing, not closing, and running all the fun stuff, I'm actually very curious to see this thing go on.

I believe I've made it all the way to the end with a million connections—a million connections—without it failing. So, I feel like this is going to be a fun time to now go to the next level, which is the proxy. I want to be able to proxy out my games so that I can run them and not die. I think that would be a lot of fun! I want to be able to have UUIDs that actually route to specific games, allowing new games to be created, and I can figure out fun ways to do multiplayer.

Anyways, I don't know how to do any of the proxy stuff; I've never built a proxy myself. I understand it with boxes and arrows, but I don't understand anything else about it. So, it seems like it would be really fun. You can proxy these nuts on your chin from your angle—got it, buddy!

Proudly, something that we employ in the Rails stack by default is written in Go because Go is better at that part. Let's do that! He's right; Go is really fast. In Kevin's testing on his personal laptop, he was pulling 60,000 requests per second. Now, I know you could run all of Shopify on your laptop in the corner if you just wrote it in Rust. I know that's possible, or at least that's what people on the internet tell me. But I might write my proxy in Rust, though, just to try it out, you know what I mean? Just to see if we can do it.

Okay, but I love this! I'm loving this! I love this take, dude; it sounds so good. It's so good! Go is just enjoyable. I'm glad that he didn't go fantastic. This is not going to be your bottleneck; that's all that matters. This is not going to be your B neck.

We have Kamal 2; this is how you're going to get your application into the cloud, into your own hardware, or into any container, or anywhere you want to put it. We're not going to tie ourselves up on a PaaS. Harris was the missing element for us to go from declaration—we're leaving the cloud—and that was step one. Then I had step two: question mark, question mark, question mark—how are we going to do that to profit? The missing bit was introducing Kamal. Kamal 2 levels this up substantially.

So, with Kamal 2, you can be unburdened by what has been. Is that what you're telling me? I know you were in the cloud, but now you can officially be unburdened. Damn, that's cool! SSL is handled automatically through Let's Encrypt, so you don't even have to know anything about how to provision an SSL certificate. It allows multiple applications to run on a single server, so we scale down as well as scale up.

It comes with a really simple declaration setup for WH, detailing what your deployment looks like. This is basically it; the entire setup is encapsulated in the fewest possible pieces of information, as close as possible to no config. It is backed by a brand new proxy that is also written in Go. We replaced Traffic with the former proxy of Kamal to make it even easier and faster, supporting Auto SSL and multiple apps with zero configuration. That was the mission for all of Kamal: how can you have no configuration at all to set up this stuff so you don't even have to understand the concepts required?

Nice! Cal is dope; you can actually use it for more than Rails. Oh, that's cool! So, it is just true; it's just something that helps you effectively run your app. It's just a proxy to run your app all nicely. That's cool! I want to go check it out now.

Now, for the orchestration of it all, I'm going to show you a quick demo. Pay attention; it's only five minutes and goes real fast. The precept is that I have two domains set up that both point to a single server. The application's going to live on Alpha, and they're going to live on Bravo. I have a Docker Hub.

=> 01:52:28

Deploying your app has never been easier—just a few commands and you're live with no complicated setup.

The configuration that was the mission for all of Kamal raises an important question: how can you have no configuration at all to set up this stuff? This means you don't even have to understand the concepts required. Nice, Cal is dope because you can actually use it for more than Rails. It's just something that helps you effectively run your app; it's a proxy to run your app all nicely. That's cool! I want to go check it out.

Now, regarding the orchestration of it all, I'm going to show you a quick demo. Pay attention; it's only five minutes and goes real fast. The premise is that I have two domains set up that both point to a single server. The application is going to live on Alpha, and they're going to live on Bravo. I have a Docker Hub place to store my images; that's my container. We're working very hard, by the way, to get rid of step two. You shouldn't have to use Docker Hub or any other registry service to run this, but let me show you.

Alright, let's go! We're starting a new Rails application. We're going to start it off Main, and in a little bit, you'll be able to just start with rails new. We are going to generate a scaffold application like we always would, just messages with title and body. We're going to migrate that; it's all set up already. Now, let's go have a look at our routes and connect it straight up to the root so that you can access your application on the route. When we go straight to deployment, let's test that it works in development. Yes, it does! Great! That's the old scaffold you've seen that for literally 20 years. This is how little it takes to get there.

Now, we’re ready to go to production, and we do that by opening up the deploy YAML file. We are speed-running an application, going to fill in two things: the name of the user we're going to use on the registry, and that's dhh. Then we're going to fill in the IP address or the DNS of the server we're deploying to. After that, we'll fill in the host name we're going to bind our SSL certificate to, and I think we're almost ready to go.

Let's make it M concurrency here; we're going to turn on that we have two processes and set the log level to debug so we can see everything as soon as we go to production. I'm actually going to take out a little bit more noise from the log. I found a better way to do this sooner, but this was in the demo.

What does it take to go to production? First, you have to commit everything to Git so that Kamal knows. Once you have that, we're going to run Kamal setup. Kamal setup is going to build the Docker container image off the default Docker file. It's going to stick Thruster in front, run a Docker entry point that's automatically going to set up your databases, and push that to the registry. While that is cooking, let's start another application.

Let's start Bravo, and we're going to run the same thing, but we're going to use a Rails template to essentially do what I just did, just automate it. We're going to run our scaffold, run our migration, and set everything up in the same way. This is actually a really nice feature if you make a lot of similar Rails applications; you can use the Rails template setup to do that. Bravo is set up!

Let's see if we just go straight to Dev. I ran Bravo, by the way, with Tailwind. We can add Tailwind on top, and you can get a really nice-looking, much prettier version of our trusted scaffold when you do that. It also works with a build step if that's what you want to do. By the way, that was really smart to build the same application, one with Tailwind and one without, so you can just see the difference. That was a nice demo; I really like that!

Now, let's check if Alpha is live. Alpha is live in production on a real domain name on my Hobby Hetzner server I introduced you to earlier. That's all it took! There was no pre-cooking on the server, no setup, and no installation. All you needed was a fresh plain Ubuntu box to get to that step.

Now, let's set up the second server on Bravo. We're going to run through the same step and build everything up. But while that's cooking, let's have a look at the logs for Alpha. You can run all these commands as though you were on that server, and we can see, for example, what happens here if we update a message. It is updating everything in the database. You can just scroll back as though it was local. This is really nice when you're first going to production.

=> 01:56:14

Mastering your tools can cut production time from hours to minutes, making the complex feel effortless.

Really good demo, by the way! I like that. Let's check if we are live. Alpha is live in production on a real domain name on my hobby Hetner server I introduced you to earlier. That's all we took; there was no pre-cooking on the server, there was no setup, and there was no installation. All you needed was a fresh plain Ubuntu box to get to that step.

Now, let's set up the second server on Bravo. We're going to run through the same steps and build everything up. But while that's cooking, let's have a look at the logs for Alpha. You can run all these commands as though you were on that server, and we can see, for example, what happens here if we update a message. It is updating everything in the database. You can just scroll back as though it was local. This is really nice when you're first going to production and trying to figure out if everything is working, seeing that everything is set up.

We can run a console; Kamal 2 has aliases, so you just write command console, and you are in the production console on the server right away. You can update all your models. Let's update that, for example, changing the title of this message and checking—voila! We updated straight from Toronto! Woohoo!

Alright, let's go back to Bravo here and see if Bravo is in production too. Oh, it is! Look, bravo.exitsoftware. It is in production. Both of these applications are running with automated SSL setups on the same server. It even runs with cable, it even runs with live updates, it even runs with the caching, it even runs with the queueing. Everything is preconfigured. It's running on SQLite in production with all the real stuff you'd actually use for a real application. It's kind of incredible.

Now we can go back here and see you've got the supervisor entering something in the log, so you see that's alive. Let's do an update and go back here to see we have an insert into the solid CU jobs. It actually ran the real job. The job queue is set up; it actually does run, and it does the action cable updates over action cable that again flows through solid cable. Then we can remove it all.

That's it, Cal remove y. Now, to be completely fair, for me to do the exact same thing, this would take like a full day. I'd have to read a lot of documentation. Okay, this is what this is—what knowing your tools—this is the benefit of knowing your tools, I guess. It's pre- so it makes sense. Yes, it is all speed; it is all pre-recorded. You even saw one of the things said it took 60 seconds, right? They just dropped the 60c part, but the idea of being able to know your tools and run quickly is pretty nice.

It is pretty nice to be able to speedrun these things. We’re cleaning the box again from our entire application, and if you just remove one, you're going to get a bad gateway with this beautiful 502 from proxy. And that was it. Was that VCL? Was that got little VCL right in the background? What a lovely cone—or VLC. Yeah, if you watched the original Rails video, we spent 15 minutes making one application and did not go into production. That was 2005. Now we spent five minutes taking two applications all the way to production, and one of them even looked rather nice with Tailwind.

That’s a compression factor of six! We have compressed complexity by an order of six times over what we used to have to get to production, yet somehow it still actually looks familiar. He did that on purpose, I swear. This man knows things. Okay, he knows things, and you know he knows things. You don’t just put that up there for no reason.

Okay, Brazil is actually mentioned! Let’s go! Let’s go Brazil mentions! These are definitely some Brazil mentions. Let’s go! Let’s go, Brazil! This is almost the original scaffold that we have. So that is Rails 8. We have authentication, we have a new acid pipeline, we have a solid trifecta, we have a thruster, we have Kamal 2, and it’s giving us no buildt; it’s giving no pass. It’s incredible! And it’s going to be available today in its first beta shipping momentarily.

Rafael, right? Yes, great!

[Applause]

Now, as long as I can prop shaft thrust that Pumba, I think we're good. Not only is Rails 8 going live, but Kamal 2 is shipping today in final form momentarily. Solid Q is shipping in its final 1.0 today momentarily. All these things are actually ready to use. For once, I didn’t have to come here to talk about vaporware. We are live! All of it is out there. I hope you start your first Rails application!

=> 02:00:40

Great software is out there, ready to empower you to build anything you can imagine. Don't wait—start your first Rails application today!

Authentication is a key focus as we introduce a new ACID pipeline. We have a solid Trifecta, a Thruster, and Cal 2, all of which are delivering incredible results with no buildt and no pass. This is truly remarkable, and I am excited to announce that it will be available today in its first beta shipping momentarily. Rafael, right? Yes, great!

Applause

As long as I can prop shaft thrust that Pumba, I think we're good. Not only is Rails 8 going live, but Kamal 2 is also shipping today in its final form momentarily. Additionally, Solid Q is shipping in its final 1.0 today, momentarily. All these advancements are actually ready to use. For once, I didn't have to come here to talk about vaporware; we are live, and all of it is out there. I hope you start your first Rails application today.

It's pretty good; you know, Ruby looks really good. It's shocking how much good software there really is out there. I’m going to be just completely honest: no matter what you think of Next.js or Vercel, it's still an amazing platform. Obviously, the looks of this are really amazing. I have not used it, and I don't know Ruby even in the slightest. I have massive respect for DHH, but still, this looks amazing.

Laravel is another framework I've never built something with, other than that small little thing I did with TJ. It looks amazing! It is shocking how many good things are available for people to build whatever they want. Life is shocking how good things are, and I'm sure Elixir is even better than all of them. However, bless my heart, I haven't dived into Elixir yet, and I just haven't done it. I'm sure it's amazing; the DX is off the charts these days—it's true!

Applause

Now, I'm already three minutes over, but I wanted to give you a little taste. Do you want a little taste? Wow, we're already at 8.1! There are a bunch of things I would have liked to have in Rails 8. We have already jam-packed it full of goodies, but I would also have liked to include Action Notifier. Action Notifier is a new framework we've been developing to handle web push notifications, allowing us to move away from needing native applications. It's going to be great!

If you have been on Campfire, the conference chat, you are already receiving push notifications if you signed up for them through the early version of Action Notifier that lives inside of Campfire. It's a pretty simple framework, but there are some complexities you need to deal with to set up the web service workers. These service workers connect to a subscription, sending it all out reliably. We are going to wrap it up.

Unfortunately, nobody still knows how service workers work. I know they exist, and I'm sure that same guy who writes all the REX on Stack Overflow also knows how service workers work, but that's it. It's unfortunate; it's really unfortunate that this is how the world works. I know they exist; it's just that they're not actually possible to set up. The code is all there; it's incredible.

Active Record Search is a new project we started on the same premise, based on the idea that Elastic Search can give us bad vibes when we go to production. Elastic Search is a wonderful piece of end-user functionality, but it tortures methods for developers and operators. We are going to solve that because most people do not need all the firepower of Elastic Search; they just need to search their Active Records. We can solve that problem with a fraction of the complexity.

Active Record Search is going to be exactly that. It will look something like this: you will declare which variables or attributes are searchable and how they are searchable. Wouldn't it be nice if you could search it like this: post.search announcement? Wouldn't that be nice if that was all you had to set up? Yes, it would be very nice!

These are the three main methods we are using. Again, like all the other solids—well, I say all the other solids—this was called Solid Search until I realized that it doesn't make any sense. Active Record is already a database; this is not an adapter for another database. So now it's Active Record Search, but it's built on top of it, doing these things.

Finally, we have Action Text, which we have used in all our applications. In our latest applications, we are using Action Text with Markdown. Markdown is a wonderful format!

=> 02:04:37

Stop settling for clunky editors; embrace Markdown for a smoother, more efficient writing experience.

Search it like this post search. Wouldn't that be nice if that was all you had to set up? Wouldn't that be nice if it was just out of the box, available right away? Yes, it would. It would be very nice.

These are the three main methods we're using. Again, like all the other solids—well, I say all the other solids—this was called solid search until I realized, you know what? That doesn't make any sense. Active Record is already a database; this is not an adapter for another database. So now it's Active Record Search, but it's built on top of it, doing these things. Finally, we have Action Text, which is something we've used in all our applications. However, in our latest applications, we are using Action Text with Markdown. Markdown is a wonderful format for formatting text; a lot of people would prefer that over a WYSIWYG editor. We're going to build that straight into Action Text, and it's going to be called House MD.

How is House Markdown not already a thing? How is House Markdown not already existing? It is now copyright; it's getting a little bit close. But dude, that's crazy that House isn't just already an open-source thing. House is already powering the right book application that is actually free.

Can we take a pause? Can we all just agree that Jira's editor is the single worst thing that has pretty much ever existed? You never quite get it right, and eventually, you just end up deleting huge chunks of your text and restarting it all over again because you can't quite get the things to work. This whole idea of "squirly brace code"—squirly brace, and you got to put it on both sides—it's just... I just hate it. I hate everything about it. I never want to ever look at it again in my lifetime. Why not just Markdown? Please stop with these WYSIWYG editors; they never work well.

To be fair, the worst one was Confluence, but nobody likes Confluence. I try to avoid Confluence as much as I can. Every time I say that, someone always comes in saying, "Well, actually, Confluence isn't that bad." No, Confluence is that bad. Okay, Confluence is horrible. Stop it! Rich text editors are awful; just stop! We don't need it; we don't want it. Just get the hell out of here. Our life can be so much better without it.

You can see how it works; you can see how all the sources are in there. That's a small taste of Rails 8.1. We have so much good stuff in store—Rails 2.1—plenty of things coming, but I'm just going to digest it all for a moment and enjoy my red circle. That's it. Thank you!

Applause Thank you, Shopify! Wow, that was amazing. Thank you, thank you, and thank you, dude DHH! What a great presentation. Should we get DHH back on here again? Markdown is literally the best; Markdown is an amazing format. DHH was great to have on here; he said he would come back on again at some point. That was just absolutely amazing. I've had a great time; he is funny—a funny man who gets excited about things.

Yeah, that was great—absolutely fantastic. Thank you, everybody, for hanging around. I know I owe a lot of thank yous and all that. I do want to get right into something else that I saw here that just looked so exciting, and I wanted to look at it. Where did it go? There’s something I really, really, really, really, really wanted to mention. It was only a couple of moments—it was like C++—the creator of C++.

Look at that! The founder of C++ on how long it should take to learn a language. Tell me that thought! Awesome!

Hey, the name is... Thanks, DHH, that was really good. You know, I feel like there's too much to learn in life. I'm so excited to learn so many different things. I guess I'm just going to have to be happy with my proxy and start there and go from there—one thing at a time, people, one thing at a time.

But real talk: you should learn something, enjoy it. Learn the things you really want to learn; learn the things that are going to make you more confident in the area you want to work in. That's what you should always do. It's just so much better in life. You know, if you develop something and every time you talk about it or get near something and you feel really kind of uncomfortable, just remember that that's probably something you should just learn. It's not even that hard.