Ryan Stout
Panel: Post-Rails World
See all speakers
See all 3 speakers

Summarized using AI

Panel: Post-Rails World

Nick Sutterer, Ryan Stout, and Jim Gay • March 11, 2015 • Wrocław, Poland

The video titled "Panel: Post-Rails World," presented at the wroc_love.rb 2015 conference, features a discussion among speakers Ryan Stout, Nick Sutterer, and Jim Gay on the implications and challenges of migrating from Ruby on Rails to other frameworks in the Ruby ecosystem. The panel delves into their personal journeys and frameworks, specifically Volt, Trailblazer, and Lotus, as alternatives to Rails.

Key points discussed include:

- Framework Evolution: The speakers discuss the necessity of developing frameworks that extend beyond Rails to solve issues faced in application development, highlighting personal experiences that led to their creation.

- Framework Interactions: A conversation about how different frameworks like Volt and Trailblazer can be integrated and their respective roles in managing business logic and UI decisions was emphasized.

- Client-Side vs. Server-Side Logic: The panelists argue about the duplication of code between front-end and back-end in Rails and how Volt attempts to streamline this by validating on both the client and server side.

- Designing for Growth: The conversation reflects on the importance of designing systems that are adaptive and scalable, considering how developers can outgrow existing frameworks as their projects evolve.

- Framework Characteristics: The speakers shared insight on challenges with error handling and increasing complexity within Rails that pushed them towards alternative solutions that allow for clean architecture and modern development practices.

- Reflection on Choice: They suggest that developers should reflect on their needs when choosing or learning frameworks, balancing between current capabilities and future adaptability.

Throughout the discussion, personal anecdotes and insights into the process of creating frameworks serve to illustrate the practical concerns developers face when moving beyond Rails. The panel concludes by emphasizing that experimentation and feedback from the community are vital for future success in development practices. They encourage the audience to apply the concepts discussed into their projects, remaining open to future possibilities and adjustments.

Overall, the session illustrates a thoughtful exploration of frameworks in the post-Rails landscape, encouraging developers to consider structural adaptability and community-driven growth in their practices.

Panel: Post-Rails World
Nick Sutterer, Ryan Stout, and Jim Gay • March 11, 2015 • Wrocław, Poland

wroclove.rb 2015

00:00:08.800 Welcome to what is considered the best PHP conference of the year. Today, we'll discuss how to migrate from Rails to PHP.
00:00:16.209 Yes, that's why I wrote Lotus. Okay, let me be serious for a moment. How's the weather in Italy? I hope it's nice.
00:00:25.599 Please give a big hand to our three speakers. We will have a discussion panel, and I expect everyone in the audience to have a lot of challenging questions.
00:00:34.780 The discussion will focus on the post-Rails world. So, you two have written frameworks that go beyond Rails. How did you come to that decision?
00:00:51.460 Okay, I'll give the non-stupid answer: it was necessary. I needed to write a book about it. Over the past ten years, I've been working on gems like Cells and Rails, but I have only made eighty dollars from donations in that time.
00:01:04.089 That's amazing! I actually had more money than that; I just don't know where it went.
00:01:10.030 But seriously, did you already buy yourself a boat?
00:01:16.680 It’s a very small one! I have a question: how do Volt and Trailblazer work together? That's a good question. I should really check out Trailblazer.
00:01:28.810 It seems you didn't catch my talk at the conference. I missed most of it because I had to leave.
00:01:37.989 I did listen to yours, though! From what I understand, Volt allows you to combine back-end and front-end logic in Ruby. But how do you handle business logic, like creating a comment?
00:01:54.700 When it comes to form submissions, it's primarily client-side, similar to how it's handled in Ember, where most code runs on the client and communicates with the database for validations and permissions.
00:02:05.980 This means validations need to run twice - once on the client and once on the server. The backend can dispatch operations based on these validations.
00:02:18.610 In that sense, there should be some binding mechanisms, but it’s likely nothing will replace Rails since it’s deeply rooted.
00:02:37.129 In terms of validation, they reside on the model itself. We do not have them abstracted away, but Volt’s models can handle persistence differently. You can instantiate a model and declare where it should persist.
00:02:50.720 I don’t think you could just use ActiveRecord with it. You still require some form of persistence.
00:03:06.360 Volt models come with callbacks alerting when their state changes, allowing you to create a persister class that can handle that.
00:03:17.880 I think I understand Volt a bit better now. I wonder how Trailblazer and Volt would look outside of Rails. You two are addressing various concepts, right?
00:03:29.890 Actually, that's why I'm quite frustrated that Luca isn't here, as we started to prototype the integration. It’s not special to run an operation in a Lotus action; Lotus actions are very much like Rails controllers.
00:03:41.210 You can dispatch to an operation and use Lotus views or Cells, as Cells are already decoupled from Rails. We started prototyping, but I haven't had the time to finish it as I'm busy with my book.
00:03:58.000 Also, please buy Jim's book and Ryan's upcoming book. We need to promote our work!
00:04:10.000 Treblazer is decoupled from Rails, and I mainly use Rails for marketing since a good portion of Ruby developers initially start with Rails.
00:04:31.890 Yes, it’s a challenge to create applications that can grow and evolve. Systems like Trailblazer and Volt try to address some of those issues.
00:04:44.310 As we explore what comes after Rails, we should reflect on what we think is wrong with Rails that led you to create other frameworks.
00:05:06.450 From my experience with Volt, I loved Rails initially, but with time I noticed many duplications in the code, especially between client-side and server-side logic. This duplication makes it harder to maintain.
00:05:25.040 I want to build apps where search engines can index all content, which means we need it to be available on both back-end and front-end.
00:05:49.500 Volt was actually my attempt to eliminate much of that duplication and maintain a clean architecture that enables me to work on both the front-end and back-end.
00:06:03.400 What about you, Jim? Do you agree or disagree? I believe that for every expert, there’s an equal and opposite expert. It’s important to consider the experiences with the frameworks you employ.
00:06:17.210 Frameworks save us time by helping us learn others' ways of working, but ultimately you'll find patterns that work best for you.
00:06:29.200 With frameworks such as Volt, Trailblazer, and Lotus, we’re discussing different ways of working and how people might outgrow those tools as they evolve.
00:06:43.210 While frameworks, such as Rails, do some things for us well, the costs of implementing bespoke tools could be lower compared to others. Modern development calls for flexibility.
00:06:59.140 It sounds like each framework tackles different aspects of application development, which is a great opportunity.
00:07:08.490 It’s important to design systems that can grow and adapt. I found using different notions of what’s wrong in Rails is what prompted the creation of other frameworks.
00:07:23.890 Let's revisit what aspects we believe were fundamentally wrong with Rails at its core, which prompted the evolution of newer frameworks.
00:07:38.299 I believe that one of the primary issues I encountered was a significant amount of repetition between back-end and front-end code in Rails.
00:07:52.250 In my experience, Rails has become increasingly complex, pushing me to find solutions elsewhere that better suit the fast-paced nature of modern web applications.
00:08:05.210 What do you think contributed to your own evolution, Jim? Error handling is a significant factor when navigating through frameworks and is critical in development.
00:08:17.220 Having frameworks that handle errors gracefully enables smoother development without systems breaking mid-task. What were your thoughts?
00:08:31.230 I think my experiences have informed how I approach frameworks, and it’s essential to consider not just how we use a system, but how we hope to grow with it.
00:08:45.530 I encourage our audience to contemplate how to structure your projects; it's all about considering ways that can allow for future improvements.
00:09:03.470 At the end of the day, we want to make our frameworks more accessible to everyone.
00:09:16.840 Should we employ frameworks based on our current capabilities? Or is learning multiple frameworks viable?
00:09:30.710 Each approach has its merits; it’s all a game of trade-offs in choosing what works best for specific applications.
00:09:44.150 In terms of application features, should we focus on core functionality? How far can we push our frameworks?
00:09:59.790 The bottom line is that opportunity for growth comes through experimentation and community feedback.
00:10:15.650 Ultimately, our discussions today have illuminated some exciting possibilities for development.
00:10:26.479 As we conclude, I urge you to carry forth the knowledge gained here in your own unique environments.
00:10:41.080 Thank you all very much for your time and engagement. Let's look forward to catching up during the party tonight!
Explore all talks recorded at wroclove.rb 2015
+3