00:00:12.599
I had no idea just how much work went into this until I saw it from the inside. It is astonishing how much preparation it takes to put on a show like this. Absolutely incredible! The fact that Amanda also managed to coordinate the weather with Rails 8 releasing here is just fantastic.
00:00:23.560
So, thank you to Amanda and the entire team.
00:00:29.000
The topic of today is Rails 8. I am going to dive into all the wonderful new features, libraries, and everything we’ve got going on. It is one of the most exciting releases of Rails that I can remember. We have to go back at least to Rails 7 for me to have been this excited about a new release.
00:01:04.760
I want to spend a little time talking about Rails 7 because it set a new tone, in my opinion, for where the framework is going and the confidence with which it meets the world. For a while, we were taking cues from the rest of the world and realizing that the front end was moving in one direction and the cloud in another, and that we just had to follow along.
00:01:21.960
However, I began to feel uneasy about that sense of following, because there were parts along that path that didn’t make sense to me. I didn’t have a good way to articulate that at the time.
00:01:36.400
For years, I felt we could do better, even at the launch of Rails 5 when we integrated Webpacker. I thought, 'This is something we just have to do.' It wasn’t necessarily something I was super excited about. Rails 7 brought back that excitement, because it felt like there was finally an opportunity to realize a vision that had been growing for a long time and to give us a map toward future releases of Rails that could develop that confidence.
00:02:05.520
One of the lenses I have been using to guide that has been the idea of a pattern language. You have a problem, a context, a solution, and some consequences. When I looked at all the things I did not like about where the web was going, it was patterns that felt stale – patterns that had been marked for garbage collection but had not yet been picked up. Patterns that were no longer relevant in the context that we were able to push forward.
00:02:43.680
The change of context for me was the underlying change in web technology. It was the introduction of ES6 JavaScript being good straight in the browser with no transpilation. It was the fact that HTTP/2 had made it unnecessary to bundle items into big units. Finally, import maps allowed us to write modern code directly for the browser. The pattern invalidation that came from this was clear to me.
00:03:21.280
We used to have a pattern that said you could open four connections to the browser, and you had to wait one at a time to open more. Therefore, we must bundle everything. We had a pattern that said browsers really struggled with JavaScript, so we could transpile those ideas into better JavaScript. Those advances invalidated that context; those ideas no longer made sense.
00:04:05.519
As software developers, there are two things we are historically bad at: naming things and cache invalidation. It’s the cache invalidation of mental models that I care most about; that’s where I really see the lag. The context of ES6, HTTP/2, and import maps had happened years in advance of our full advantage, well after people thought, 'The way to build for the web is through long cumbersome complicated build pipelines.'
00:04:44.560
This context is rediscovered, and we realized there’s a bunch of patterns that no longer make sense. For Rails 7, part of the answer to that new context was Hotwire—here’s a new, simpler, more modest way of writing JavaScript that goes together with your back end, and it works beautifully in that new context.
00:05:02.800
It is a pattern fit for 2024; it was not a pattern suited for 2012. It was not a pattern that fit a time before we had gone through the necessary jungle of complexity that allowed us to arrive at a simpler place. My work on both Hotwire and figuring out which of today’s patterns were no longer relevant was, as always, driven by extraction. We are not in the business of making speculative frameworks; we are in the business of taking solutions that have been proven to work in real applications with real customers under real production pressures.
00:05:51.440
We take those solutions, package them nicely as gifts, and then share them. That’s what we do here, and my work on Hey was that path that led to the discovery of those new patterns. It validated that, you know what? The whole industry is wrong—a sentiment that is often the basis for Rails 7’s approach to the frontend; everyone is wrong. We do not have to accept heavy build pipelines, bundling, tree shaking, or any of the other premises of modern web building as facts. We can write a different story.
00:06:19.520
What’s interesting is I started working on Hey in 2018. I foresaw some of these trends coming, but it wasn’t quite ready yet. Even at the launch of Hey in 2020, it wasn’t fully there. We had structured our things around Hotwire, but we were still using Webpacker at launch. It took about a year for us to fully realize these ideas and move them forward. In fact, it was not until yesterday that we were able to go 100% no build for all of Hey.
00:07:01.440
There is no build line in the JavaScript, there is no build pipeline in the CSS—all of it is served directly to the browser as we wrote it. The benefit for me is not just personal satisfaction in being able to realize these patterns and new ways of thinking, but also to provide an irrefutable anchor point for the discussion about whether this is even possible on the internet.
00:07:48.720
There is an endless cacophony of people telling you that the thing you’re trying to do will not work. They insist 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 successfully 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; we have proved that.
00:08:32.560
I think of the yearly tweet from Toby as a perfect embodiment of this phenomenon. For 20 years, people have told us that Rails does not scale. In November of last year, Toby tweeted about doing one million requests a second on the largest Rails app in the world. This is a monument that says, 'Shut up, this argument has been settled.' We don't need to rehash this; just see the tweet. The tweet is the monument.
00:09:20.920
Now for the tangible benefits. This is how Hey is loading JavaScript: there are no source maps, there is no bundling, we are shipping everything straight to the browser as we wrote it. I look at that with 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.
00:09:59.680
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 use 'view source' if you are tree shaking or bundling. You can try to patch it on with some source mapping, but now you're piling more complexity on top of the complexity, and the tower will fall.
00:10:54.520
The other realization for me was the initial trigger that got me interested in no build for Rails 7 was just an infuriating annoyance of being unable to compile a JavaScript project I had carelessly left unattended for about five minutes. None of the tools worked; everything was outdated. When I tried to update it, I literally couldn’t figure it out. I spent half a day wrestling with Webpacker, and I turned over the table, saying, 'No! I made the integration for Webpacker to Rails, and I cannot figure out how this works!' There was something deeply, fundamentally broken about that model.
00:11:49.600
And that’s when I realized the truth—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 complaints. That is the beauty of the modern browser. It is a beast of complexity, and I wouldn’t wish it on my worst enemy to try to implement one from scratch today. But the benefits we, as web developers, reap from the fact that browsers have gotten this good, with such a commitment to backward compatibility, are incredible.
00:12:40.760
The idea that you could design something in, let’s say, 1995, and it still looks the same today, thriving as one of the biggest websites—this is Craigslist. I don't believe they have changed an iota of that design since it launched in 1995, and it still works. Not only does it still work, but it still thrives. That level of longevity in software development is something we should aspire to.
00:13:31.160
As inspiration goes straight through the browser, the truth of the browser being the runtime of all this code is paramount. The more we can remove 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.
00:14:08.480
Now, saying all that, another principle that we have straight out of the Rails doctrine is the idea of pushing up a big tent. I have been incredibly excited about what we were able to do with Rails 7. All the code we write at 37 Signals is no build. Every single application we made since Hey has been built without any form of JavaScript compilation or CSS pipelining. That’s incredible! It’s not for everyone—it doesn’t have to be for everyone. The ideas I’m pushing forward connect to an overarching mission of creating a one-person framework with an on-ramp that is on the freaking floor, making it accessible for anyone to step on.
00:14:53.240
Fundamentally, it serves that mission as well as my enjoyment as a web programmer. However, it’s not a dictate. One of the things that has allowed Rails to thrive, from Hello World to IPO, is the flexibility of allowing folks to opt into the parts they choose while opting out of the parts they prefer to do differently. That’s wonderful. Many tons of applications have been built with everything from React to other frameworks, and that’s great!
00:15:50.320
What excites me; why I’m still here—why, after 20 years, I can get as fired up as I did on the first day—is that we are pushing toward a clear, bigger mission. That bigger mission involves invalidating patterns that no longer bear context—patterns that have become obsolete—this what gets me fired up.
00:16:32.160
I tweeted this out a while back, and in honor of having Matt here at RSW, I rewrote it as a haiku: progress is our path, complexity builds the bridge, simplicity waits. What I like about this sentiment is the idea that complexity is a necessary ingredient to progress, but that’s not where we stop. We are not done when we’ve solved complexity; we are done when we’ve made it simple. That’s a very different philosophy on when to stop and when to get excited, one that I try to embrace in everything going forward, including Rails.
00:17:25.000
This is the dividend: 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, has made it so much better and more fun to be a web developer without extraneous tools. We've streamlined it by saying this application is just for modern browsers. While we can't do that for all applications as some must support a longer tail of compatibility, we can do it for many. If you're starting a new application today, you should absolutely do this.
00:18:48.839
Okay, there’s an even bigger purpose here. The purpose is not just to find the best patterns or seek simplicity for its own sake, although that is a gift. The purpose is to optimize for our limited monkey brains—they simply can’t fit that much. If we are going to spend all of our time learning the intricacies of some complicated build pipeline, there’s no room left for anything else.
00:19:49.200
What I want to make room for is making space for the full-stack developer—someone who can see an entire problem and a complete solution and keep it in their head for as long as possible. Eventually, it won’t be possible to keep all the necessary details, as no one can possibly store five million lines of code in their main monolith in their head at once. However, the journey of enabling someone to do so is crucial.
00:20:23.839
People talk about how Rails is great for beginners, but then they question, 'What are you going to do when you’re making billions of dollars?' What do you mean, 'What are you going to do?' You’re going to do whatever it takes, because you’ll have all the money in the world by then. The problem is not how to be slightly inconvenienced once you have that money; it's not a zero-to-one problem, it’s how to reach that 'billion.' That’s the path!
00:21:38.000
To look at this problem, we must compress all those parts of the modern web development experience into units that fit together. I learned a valuable lesson when I picked up Vim again. Vim is one of those funny things that take a lot of your brain space. You need to find a way to compress it so you can fit anything else, like the name of Jason here; I think he would be slightly offended if I called him Jarvis, my business partner.
00:22:36.839
It’s essential to utilize the available cognitive space well, compressing what is inside, so we do not have to subdivide this industry into tiny slices of expertise. That’s what you do at a certain scale; that’s a billion-dollar problem, not a zero-to-one problem. It’s a mission that reads: compress the complexity of modern web apps with a focus on transitioning from Hello World to IPO.
00:23:23.520
What’s missing is the bridge to the IPO, and the first step on that bridge is deployment—taking an application that’s running on your machine and making it available on the worldwide web for everyone. Over the past ten years, 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.
00:24:19.360
When I have my Dr. Evil hat on, I think it’s amazing that you’ve convinced programmers that computers are so hard they shouldn’t touch them. But it’s pathetic! Do you see how tiny that rope is? Do you know how much mass an elephant has? Do you know how little it needs to move its foot to escape that rope?
00:25:00.399
The reality of this situation is that I love how far this discourse has advanced—I don't even have to make the joke. The problem with AWS and similar services is that they're amazing, as they provide an entire army of server monkeys behind an API that can operate quickly and efficiently, but most of us don’t live in that context.
00:25:48.119
Most applications, most of the time, do not require constant racking of server monkeys behind an API. The price we pay for our insurance policy is exceptionally high—not just monetarily, but complexity-wise. Furthermore, AWS is a business, and the incentive for AWS is for you to stay a pink elephant forever, to be petrified of running your own servers and managing your own systems.
00:26:47.120
Hence, we are not going to let the Joker win! We are not going to buy into the premise that servers are so difficult that AWS should have a 40% margin, when makers of the actual computers have 5% margins. That is a failed market, an uncompetitive market where super profits are not challenged!
00:27:36.960
Before we take action, let’s do a shoutout to Heroku, which, to me, represents one of the greatest breakthroughs in developer ergonomics. The fact that it emerged in 2007 before most of us had a broad conception of what containers were, and the fact that they managed to sit on that advantage for over a decade, is truly mind-blowing.
00:28:38.160
Heroku’s achievement of reducing deployment to a simple 'git push' has enabled countless Rails developers to move from Hello World to their applications being online. However, we are now in a situation where Heroku's pricing no longer reflects the reality of hardware availability.
00:29:26.840
For $250 a month, you get the luxurious One Core, two to three threads, and 2.5 GB of RAM. I’m sure that sounded pretty good in 2012, but in 2024, that’s preposterous! What is the difference between that and paying $220 a month for 40 cores, 96 threads, and 256 GB of RAM? It is simply the software!
00:30:12.500
Heroku has nice software; I think I could make nice software too. Why would I pay a hundred times more for my RAM or 50 times more for my compute? We need to acknowledge that we’re overdue for the generics in deployment, as the price point for fantastic skills has skyrocketed into outrageous levels.
00:31:49.120
The mission for Rails 8 is a framework that does not require paying a commercial vendor to go from development to production in an approachable way. We are aiming for a space where the services are there as optional extras for minor use cases.
00:32:27.679
We have been infected by server phobia, which makes us think that servers are something to be avoided or feared. This is a false premise; you can get over server phobia, and the way to do that is through utilizing Linux. Linux runs not only our servers but also your personal computers.
00:33:17.919
I built Amak coup as a project to transform a scary Linux machine into a productive, comfortable, good-looking Linux setup. I invite you to give Linux a shot and experience a great discovery. A great example is 'House,' a new editor framework that has made me realize how valuable alternatives can be.
00:34:30.639
Security is another aspect I get frustrated about. Here’s a cheat sheet for securing a server: put an SSH key on it, make it such that the SSH key is the only way you can authenticate access, and start a nicely UI-managed firewall, and you’re mostly done.
00:35:00.000
The more fun we can have being competent and knowledgeable, the more enjoyable our work as developers will be. This is the beauty of the toolset we now have available to us, allowing us to reach back to our roots and achieve efficiency.
00:35:45.160
Now let’s discuss Rails 8 features that serve this mission. The first feature of Rails 8 that I’m really happy to present is the new way of implementing authentication. We will generate the authentication code so that you actually see it and understand it.
00:36:23.680
Rails 8 won’t ship with a black box of security; it’s about teaching you how to implement it efficiently, without relying on third-party solutions. This 90% ready authentication system is a great starting point for learning secure password practices.
00:36:57.480
Another proud achievement is Propshaft. In Rails 7, we embraced modern web stacks and realized that the asset pipeline, as it existed, was outdated and overly complicated. Propshaft represents a clean slate aiming to work perfectly in the current context.
00:37:34.920
It’s built for those times when all we need is a load path and to digest assets for the future. This allows us to have a smaller and clearer codebase with fewer issues. Moreover, the modern web application used to require a plethora of data storage solutions, but we can collapse that down into one database system, leveraging speed and simplicity.
00:38:19.880
Rails 8 will introduce a trifecta of database-backed adapters called Solid. We have Solid Cable for backing WebSocket communication through databases, Solid Cache for caching in the database, and Solid Queue for running jobs, all from a single database system.
00:39:09.680
Furthermore, SQLite removes the process you need for operational management and instead relies on a collection of files. This incredible simplification allows anyone to start a new Rails application without needing to set up a traditional database server.
00:39:58.120
With Solid Queue, we’ve created a high-performing solution for job management, eliminating the need for multiple gems for job processing, which is a common pain point. Solid Queue can run with different databases and offers full functionality with built-in support for recurring jobs.
00:40:45.680
I’m excited about the efficiency with which we can now operate—over 20 million jobs per day just on Hey, and together with our other systems, we’re processing around 100 million jobs a day. This new way of doing things makes it easier, cleaner, and allows developers to ditch Redis if they need to.
00:41:35.560
With the new features in Rails 8, especially focusing on Solid, we also wanted to manifest that our container image for Rails 8 should be directly exposable to the internet. This ensures speed and security.
00:42:28.920
Thruster handles file acceleration, cache control, and gzip compression, further improving performance without requiring additional configuration. Thruster is installed by default in our Docker image, simplifying deployment significantly.
00:43:25.480
This comes as part of our overall mission—to ensure the stack is both secure and performant straight out of the box. This is what we’ve aimed for with Kamal 2, allowing you to deploy your application without complicated server setups.
00:44:17.520
Kamal 2 handles automation of SSL provisionings through Let's Encrypt, enabling multiple applications to run on a single server, facilitating scaling. We’ve simplified the setup process to be even simpler than before, providing fast and easy images from a minimal setup.
00:45:09.920
In my demonstration, you’ll witness that deploying a new Rails application should require minimal steps—just fill in the necessary information and run a few commands, allowing you to move your applications into production seamlessly.
00:46:12.679
Now, let’s quickly set up and deploy two applications to show just how streamlined this process has become. You’ll see that everything goes live without hassles, including using great tools and making real-time updates to your production environment with ease.
00:47:29.120
With Kamal, you can now manage applications from development to production efficiently, streamlining both access and update processes. The infrastructure you’ll set up is inherently simple and supportive standalone services while integrating beautifully into the greater Rails framework.
00:48:40.080
And, when switching back to our logs, we can still observe everything happening live from user actions to processing jobs. So you can confidently engage with your application in production, knowing that it runs smoothly.
00:49:27.640
In summary, Rails 8 brings forth a plethora of features: authentication, a new asset pipeline, a powerful solid trifecta, Thruster, and Kamal 2. It’s all available in the first beta shipment, ready for exploration.
00:50:20.000
Today, we are not discussing vaporware; everything is available. I hope you begin your first Rails application today.
00:51:15.799
While I am three minutes over, I want to offer a brief taste of the potential of Rails 8. One exciting new feature is Action Notifier for web push notifications.
00:51:58.160
It’s currently being utilized during events such as Campfire, allowing users to receive real-time updates and notifications through browsers. We’re also developing Active Record Search to relieve some of the struggles developers face regarding searching across database records.
00:52:41.680
Active Record Search simplifies the process for developers without the need for complex tools like Elasticsearch while providing necessary search functionality right at your fingertips. Furthermore, Action Text is being amended to include Markdown support, making formatting easier for developers.
00:53:31.680
All of these advancements are geared toward easing the developer experience. There’s so much more we can share as we roll out Kamal 2.1 and many other exciting features are on the horizon.
00:54:21.680
Thank you—all of this is made possible by a team that is endlessly committed to the Rails community.
