Ruby on Rails
Your Front End Framework is Overkill - Server Side Javascript w/ Rails

Summarized using AI

Your Front End Framework is Overkill - Server Side Javascript w/ Rails

Jim Jones • May 07, 2015 • Atlanta, GA

In the presentation titled "Your Front End Framework is Overkill - Server Side Javascript w/ Rails" by Jim Jones at RailsConf 2015, the discussion centers on leveraging server-side JavaScript within the Rails framework to simplify the development of dynamic applications. Jones addresses the prevalent trend of utilizing client-side frameworks such as AngularJS, Ember.js, and Backbone, asserting that while they have their benefits, they may not always be necessary. The session highlights several key points:

  • Overview of Dynamic Sites: Jones emphasizes that Rails can effectively handle dynamic site functionalities using its existing architecture without the need for extensive JavaScript frameworks.

  • Comparison of Technologies: The talk introduces various technologies including raw JavaScript, jQuery, Backbone, Ember.js, and AngularJS, highlighting their advantages and uses in web development.

  • Demonstration of Server-Side Rendering: Through a live coding session, Jones demonstrates how to dynamically update a user listing in a Rails application by leveraging Rails' built-in capabilities, such as AJAX with the 'remote: true' flag for asynchronous requests.

  • Utilizing Built-In Functionality: He shows how to create user instances and update the table without pulling in additional dependencies, stressing that many developers overlook these capabilities in favor of heavier client-side frameworks.

  • Caveats and Challenges: Several pitfalls of server-side JavaScript responses are discussed, including debugging issues, event handler management, and ensuring that dynamic changes appropriately reflect in the UI.

  • Best Practices: Jones advises against over-engineering solutions by recommending a minimalist approach toward using frameworks and emphasizing the importance of evaluating needs critically before incorporating additional complexity.

  • Concluding Advice: He quotes Dan McKinley from Etsy, emphasizing the principle of solving problems without unnecessary complexity, advocating for a thoughtful examination of whether additional frameworks are needed for dynamic updates.

In conclusion, Jones claims that utilizing server-side JavaScript with Rails can lead to cleaner, more maintainable codebases while providing efficient user interaction without the overhead of client-side frameworks. The insights shared encourage developers to rethink their reliance on full-fledged front-end frameworks, especially for applications that could be handled perfectly well within the Rails framework itself.

Your Front End Framework is Overkill - Server Side Javascript w/ Rails
Jim Jones • May 07, 2015 • Atlanta, GA

By, Jim Jones
For dynamic apps, Rails has taken a backseat to client side frameworks such as AngularJS, Ember and Backbone.

Learn how to use server side javascript effectively to greatly simplify your code base and reuse your view logic. We'll implement parallel apps with vanilla Rails js responses, AngularJS and Ember.js so that we can contrast the implementations and evaluate the tradeoffs.

RailsConf 2015

00:00:11.759 Thanks for coming to my talk, everyone. I really appreciate it. My name is Jim Jones, and I work as a Rails engineer consultant. I'm currently with One Kings Lane, and I've lived in San Francisco for the past five years. I just recently moved back to Nebraska because my wife and I had a baby. I enjoy karaoke and beer, being a dad, and I really love the city of San Francisco. One of my first experiences in San Francisco was when I went to Taco Bell in the outer Mission, one of the few Taco Bells in the city. I started a conversation with the cashier, who began complaining about the rendering differences between her Windows Phone and Android phone. She mentioned the word 'render,' and I thought to myself, 'Wow, I'm in a different place right here.'
00:00:44.480 I had another experience while opening a joint account at Wells Fargo with my wife just before we got married. The banker asked me what I do for a living, and when I told him I'm a software engineer, his eyes lit up. He asked what language I use, and when I said 'Ruby,' he exclaimed, 'Oh my God! I wrote a few scripts to automate some balances I need to know at the end of the day.' It was a realization moment of where I was. I truly miss those sorts of interactions, but moving to San Francisco was a whole new world for me where I got to meet lots of people I respected over the years.
00:01:24.560 I eventually went to a company called Zents, which was later acquired by StubHub. After that, I started consulting and had a whirlwind of experiences in San Francisco that I hope to tell my grandchildren about—going through an acquisition, being out on my own, and learning independently. That's a bit of background about me. Today, we’re here to talk about dynamic sites and how we can use Rails to build them.
00:02:36.280 We have several options for creating dynamic sites with Rails. There’s raw JavaScript, which is becoming more favorable as browser implementations improve. It’s not as far-fetched as many believe. There’s jQuery, which helps manage browser idiosyncrasies. Then there are more structured frameworks like Backbone, which offers additional structure to our front end, and Ember.js, known for its nice conventions. Angular.js introduces powerful directives, adding even more structure to our applications. However, there is another option that many people overlook, which is the capabilities of the current Rails architecture.
00:03:17.360 The point is that each approach has its place; front-end frameworks certainly have advantages, but we will also demonstrate where server-side JavaScript rendering shines. We'll explore a few parallel implementations of the exact same application through live coding, although I might be committing presentation suicide.
00:03:38.960 First, I want to clarify that for anyone who's been with Rails for a long time, I am not talking about RJS, although many might still refer to it that way. This could be due to a lack of evangelism around this area. You might remember the functionality called Ruby JavaScript, which had very explicit method naming conventions, such as 'link_to_remote' and using a URL hash to specify the controller and action. We had methods like 'page.replaceHTML' that allowed us to make JavaScript requests and manipulate HTML through client-side rendering.
00:04:45.680 However, this was quite constraining, and RJS was ultimately ripped out of Rails core. I was trying to figure out when this transition took place and found that Agile 2 still mentioned RJS, leading me to believe around Rails 3 was when standard JavaScript responses were introduced, allowing for more free-form JavaScript. This change has made it easier to manage JavaScript requests. I believe demonstrating this through code will be useful, so let's get started with that.
00:05:52.280 All right, I have this application, which is just a standard Rails app—are we all good with that? We have a user model with just a name attribute. I've already performed the database migration, but that's about it for now. I want to add functionality for dynamically updating the listing of users without pulling in any external JavaScript frameworks. Let me show you how we can achieve that.
00:06:56.960 The application gives us basic scaffolding out of the box. To make it dynamic, we need to ensure we can add users to the table seamlessly. This is where the Rails framework can really help us by handling simple dynamic updates directly without the need for additional dependencies.
00:07:49.520 Let’s define an ID for the tbody of our table, then iterate over our user collection to render out all users, utilizing a user partial. I know for some of you who have seen this before, this may seem basic, but I want to emphasize that many new Rails developers often rush to incorporate a front-end framework for AJAX updates, forgetting that Rails has built-in capabilities for simpler dynamic updates.
00:08:42.760 After setting up our partial, we need to allow name input directly from the index page. We'll use Rails' built-in form generation features to simplify this process. Once we adjust our controller to create a new user, we can test the dynamic functionality. I’m going to make the form submission asynchronous by adding the 'remote: true' flag, which triggers AJAX behavior.
00:09:32.200 Let's check how our setup performs in the background. Now we see that when submitting the form, we're posting to the 'users' controller's create action as a JS request instead of a traditional HTTP post. This change indicates that we are successfully interacting with the server using JavaScript, which is essential for the dynamic updates we are implementing.
00:10:50.360 Next, let’s render the newly created user on the client side to update the table seamlessly. We will utilize jQuery, which is included with Rails, to append this new user to our user listing dynamically without refreshing the entire page.
00:11:40.880 After correctly rendering the user partial, I’m going to ensure our control logic works by confirming we processed the HTML and appended it correctly. This interaction illustrates how much of Rails’ out-of-the-box functionality can facilitate dynamic updates effectively.
00:12:29.760 Just to reiterate, this approach is not RJS; it's a much more flexible raw JavaScript implementation that leverages ERB processing. Through this method, you can reuse your partials, which is one of the significant advantages of using Rails for dynamic updates. This pattern helps keep our codebase clean and maintainable.
00:13:18.560 Now, let’s switch topics briefly. I want to introduce some parallel implementations of a todo application using various front-end frameworks to demonstrate further. This will include Ember.js and AngularJS implementations compared to pure Rails JavaScript handling.
00:14:04.800 When we look at the implementations, especially within the todo MVC application, we can see each framework’s strengths and weaknesses while also considering how the standard Rails implementation handles dynamic interactions. We'll review these code snippets to illustrate a real-world application.
00:15:04.000 It’s important to note that a big difference in the user experience is the perception of immediacy that client-side frameworks can provide due to their ability to update the UI right away. In contrast, server-side rendering through JavaScript takes more time since it depends on server interactions.
00:16:05.680 Returning to our Rails dynamic updates, we’ve discussed how raw JavaScript can be used to improve functionality. Specifically, the AJAX 'remote: true' feature simplifies the asynchronous aspect of Rails without needing extensive front-end libraries.
00:17:11.640 I need to mention some caveats of using server-side JavaScript responses. One of the major challenges is debugging. If there are syntax errors in your JavaScript, it can fail silently since JavaScript gets evaluated on the client side. To address this, we can use error handling to log any issues before the final evaluation to aid debugging.
00:18:31.760 Moreover, if you are replacing elements in your DOM through server responses, you must remember to rebind any event handlers that might have been lost in the process of replacing the content. This can easily be managed by triggering relevant events to reattach handlers or update the UI.
00:19:17.280 Lastly, I want to differentiate some of the core functionalities available through JavaScript responses. Since we’re still in action view, we can call upon partials and helpers, enabling a cleaner experience for rendering templates and manipulating the DOM.
00:20:05.200 As far as best practices go, utilizing raw JavaScript with Rails can simplify your application, particularly when dealing with forms that require persistence, like adding a comment or updating an item in a cart. The key is to ensure the user interface reflects changes intuitively without overburdening the application with additional frameworks.
00:21:02.080 In conclusion, I'd like to share a thought from Dan McKinley, a principal engineer at Etsy. He wrote an article recently advising developers to consider how they would approach solving their problems without adding unnecessary complexity, like full-fledged frameworks unless absolutely necessary. This principle should guide your decisions when seeking to make dynamic updates in your applications.
Explore all talks recorded at RailsConf 2015
+122