Rails Vs. The Client Side

Talks

Noel Rappin

@noelrappin

#ruby-on-rails

#javascript

#client-side-rendering

#single-page-applications-spa

#ember

#caching

#e-commerce

Rails Vs. The Client Side

by Noel Rappin

The video titled "Rails Vs. The Client Side" presented by Noel Rappin at Rails Conf 2013 explores two distinct approaches for utilizing Rails in combination with rich client-side JavaScript applications. The speaker addresses the increasing demand for rich client experiences, highlighting two popular methodologies: 37Signals' "Russian Doll" approach and the "Rails API" approach.

Key Points Discussed:

- Introduction to Rich Client Experiences:

- Rappin notes the desire for fast and feature-rich applications among clients who often lack understanding of their technical requirements.

- Comparison of Approaches:

- The Russian Doll approach:

- Server returns HTML with aggressive caching and some JavaScript.

- Best for document-centric applications where response speeds and caching matter.
- The Rails API approach:

- Server returns JSON to be handled by JavaScript MVC frameworks like Ember.
- Allows for dynamic client-side interactions with reduced server requests.
- Technical Insights:

- Discusses the evolution of JavaScript and how it has developed into a fundamental language for client-side coding, contrasting it with Rails' traditional server-side strengths.
- Emphasizes how client-side frameworks allow for more sophisticated user interactions by minimizing server dependency.
- Decision Making Criteria:

- Rappin advises on various criteria to determine the suitable approach for new projects:

- Stability of data representation, interaction styles (notification vs. retrieval), and the need for simultaneous component interaction.
- Importance of developers’ proficiency in JavaScript and existing systems during planning.
- Conclusions and Future Perspectives:

- Rappin posits that both methods have their merits and that complexity can vary based on the application framework chosen.

- As JavaScript tools improve, the divide between these approaches might lessen, making client-side frameworks even more viable for future projects.

Ultimately, Rappin encourages balance and thoughtful decision-making based on the specifics of the application and team capabilities, providing a framework for evaluating the suitable architecture for developing rich client applications.

00:00:16.320 Hi everybody! I'm really glad that you all came here. I'm honored to have you join me for this conference and to give this talk.

00:00:22.400 Honestly, though, how many people are here just to get good seats for Sandy's next session?

00:00:28.160 That makes me the poor comic-con panel right before the Avengers or something like that. Anyway, I'm glad you're here.

00:00:35.040 My name is Noel Rappin, and I work for a small consulting firm called Table XI in Chicago. You can follow me on Twitter at @noelrap.

00:00:49.520 Here’s my problem: I want my users to have a rich client experience. My clients come in and say they want this experience because they read about it in Wired or Forbes.

00:01:02.480 They don’t really know what it means, but they know that it involves having a fast website with graphical additions that go beyond what you would normally expect from a traditional webpage.

00:01:14.720 But beyond that, they don't really know what they want. As an architect and the person developing their site, I want to deliver this in the most efficient way possible.

00:01:21.200 Imagine you have a client seeking advice on how to build a site. You come to RailsConf, and yesterday you sit and watch David Heinemeier Hansson say, 'If it's document-based, structure it like Basecamp.'

00:01:34.400 He talks about structuring a Basecamp application and mentions five key points: key-based cache, exploration, Russian Doll caching, JavaScript decoration, and TurboLinks polling.

00:01:53.119 I'm going to assume everyone here either saw the keynotes yesterday and today or doesn’t care about the technical details. In both cases, you don’t need me to elaborate on what TurboLinks are.

00:02:07.200 So, is my application document-based? It's a bit unclear.

00:02:12.720 The next day, I see Yehuda Katz talking about how Rails makes a great API for serving JSON to a browser, suggesting that the locus of innovation is in the client side.

00:02:29.760 He mentions that we should build HTML on the browser and warns against ad hoc JavaScript and using Backbone specifically.

00:02:43.680 So now, we in the Rails community, those of us trying to build sites like this, are at a fork in the road.

00:02:50.879 The question is: should we go left, right, or jump over the fork? What is the best structure here?

00:03:07.599 Even with David and Yehuda suggesting these things, I just want to build an e-commerce site, and I don’t want it to crash. I want to be able to write my e-commerce site.

00:03:44.879 I've been writing HTML since about 1994, and I doubt there are more than 10 or 15 people in this room who can say they've been doing it longer than I have. While that doesn't mean much in this context, it’s worth noting that from 1998 to 2000, I told clients to avoid JavaScript completely.

00:04:12.400 I did this even for pull-down menus because it was such a pain to get JavaScript to work in browsers at the time, which were IE4 and Netscape.

00:04:30.320 So, that's my 'old person' cred. The last four apps I worked on include a small traditional Rails app I rewrote in Backbone mainly for the experience.

00:04:43.760 Then, I unwrapped it in Backbone because it was frustrating. I also created a hybrid front-end JavaScript application we will discuss later. I have a fully developed Ember app for a JavaScript map API which required a lot of client-side functionality.

00:05:19.600 Currently, I’m trying to figure out the direction of another application that is based on a traditional Rails CMS with e-commerce capabilities.

00:05:37.680 I want to talk about how I made those architectural decisions: why this application is built with Rails and why this one is built with Ember.

00:05:48.880 What criteria are important? It's one thing for Yehuda to say the future is in JavaScript and for DHH to advocate for Rails with TurboLinks. We still need to develop in the present.

00:06:05.600 Here’s a simplified schematic of a web application: it has a user, data, and presentation aspects. By the way, the user is illustrated in the XKCD comic, 'You're Doing It Wrong.'

00:06:27.760 This holds true for both structures—regardless of how the application is built, the user interacts with data, sending requests, and the response is converted into a displayable format.

00:06:44.639 Yehuda put a lot of effort into discussing common structures and things we can agree on. We can categorize some components as client-side and others as server-side, with some functions occurring on the user's machine and some on the server.

00:07:07.200 Irrespective of whether an application is document-based, the different schematic structures discussed by DHH and Yehuda break down like this: in Basecamp, the application primarily resides on the server.

00:07:26.960 Most people think of their application as living on the server, which enables statements about JavaScript being sprinkled in.

00:07:38.880 Conversely, in something like Discourse, the application lives on the client.

00:07:50.720 The server's role is to support the client while the application is primarily on the client, allowing more complex interactions.

00:08:02.960 There's no strict technical reason why functions cannot happen on both the client or the server; it’s more about defining where the heart of your application lies and why one approach is chosen over another.

00:08:15.280 What complicates matters is that client-side development predominantly utilizes JavaScript, while for many here, the server-side is Ruby, a language we generally prefer to JavaScript.

00:08:34.960 The existence of JavaScript in browsers is often viewed as an inexplicable historical anomaly. JavaScript has its merits, but its position as the primary browser language is due to timing and chance.

00:08:50.000 Rails has historically sidestepped JavaScript, with the default approach being to pretend it didn't exist. Many people here wrote RJS, which attempted to find important JavaScript tasks and write them in Ruby.

00:09:08.840 For a long time, this approach was rational: JavaScript tooling was poor, testing was challenging, and compatibility across browsers was a nightmare.

00:09:23.040 Over time, as we know, JavaScript tooling improved significantly, allowing better testing frameworks and debuggers, as well as comprehensive libraries.

00:09:37.760 However, many Rails applications avoided complex MVC structures in the browser and thus sidestepped creating MVC architectures that mirrored those on the server.

00:09:54.400 One way to look at this is to see it as potential duplication, where you find browser models and controllers paralleling data handling on the server.

00:10:10.080 Another view is that these structures are fractal; what appears as a view layer to the server side can develop its own MVC structure on the client.

00:10:25.680 But there remains a strong possibility of duplicated logic between client and server with existing JavaScript frameworks.

00:10:39.680 The key questions become: where is the heart of your application? Is it predominantly on the server side, interacting with data, or on the client side, utilizing server data?

00:10:54.079 In deciding for a new project, it’s important to remember that, as Nick Quinto tweeted yesterday during David's keynote, there’s more than one way to build a web app, and that’s okay.

00:11:07.600 In some respects, the stakes of choosing a structure are low; we can create functional web apps using either the Basecamp-style or the JavaScript-style approach.

00:11:22.880 However, we must also confront the question of whether we need Rails in a world that has Ember and Node. I don't wish to overly stress this point, but it does bring emotional weight.

00:11:39.520 Many of us in this room have spent considerable portions of our careers in Rails and have a vested interest in it continuing as an ecosystem.

00:11:55.280 I don't believe Rails is threatened here, but I highlight that it adds complexity to discussions.

00:12:06.640 If you're looking for proof that Rails has a lot to offer, consider the Rails API project, which is Rails with the view layer removed.

00:12:22.160 This project shows the extensive capability Rails provides for server-side applications, even if not strictly utilizing Rails.

00:12:36.960 There seems to be a disconnect between the Basecamp and Ember teams, each believing their approach is the simplest and most straightforward.

00:12:52.640 In some ways, this is an argument about complexity: you can add complexity to systems, but can't simplify them. Complexity is an inherent aspect of any application.

00:13:09.680 If you're developing a tax program, for example, it won't be simple, regardless of your tools. The question is how you manage complexity.

00:13:24.160 One approach, often linked to object-oriented programming, suggests simplicity arises from handling components separately. If I can manage my client without needing to think about the server, it reduces complexity.

00:13:45.680 Then there's a contrasting view from functional programming, which posits that simplicity derives from using straightforward data structures. Rich Hickey, in last year's keynote, discussed simplicity from this perspective.

00:14:00.320 That approach emphasizes thinking through each step of the process without complex interactions. A lot of complexity management involves reducing cognitive load.

00:14:15.040 I would argue that the client-side technique aligns more with the first definition of simplicity, accepting some additional structure for cleaner separation between client and server.

00:14:28.800 On the other hand, the Basecamp structure prioritizes simple steps and a comprehensible flow without excess structure. Each transformation step from data to display is straightforward.

00:14:44.560 Both approaches are valid, but you might lean towards one based on your programming mindset. Simplicity can also be defined as consistency.

00:15:01.680 Basecamp utilizes a less complex JavaScript setup, while managing multiple data pathways between the server and client.

00:15:17.440 In Basecamp, the server can send HTML, JavaScript, or JSON, which brings complexity, while a typical client application generally communicates using JSON.

00:15:36.960 Contrarily, client-side applications may need increased structures and might require logic duplication.

00:15:53.600 As we noted, it isn’t clear which side requires less code. Yehuda referred to the study showing that, generally, approaches aren’t significantly more complex in terms of code.

00:16:08.240 In discussions about simplicity, speed is another critical factor, with both approaches claiming to be faster.

00:16:25.040 Speed has historically been emphasized in Basecamp's marketing, while Discourse has similarly marketed itself as fast.

00:16:43.280 Assuming that lag occurs while waiting for a server response, the actual content received isn't typically the bottleneck.

00:17:02.080 In a Basecamp setup, each user interaction may trigger a server request. Conversely, in Discourse's client-side structure, many actions can happen on the client.

00:17:20.960 You don't always need to ask the server for data, as you can manipulate elements on the client side first and then inform the server about changes.

00:17:37.760 This helps positively affect the user’s perceived speed of operations.

00:17:53.680 The observation is that the speed advantage of the Basecamp structure may diminish under slow connection situations, like conference Wi-Fi.

00:18:10.560 Since Basecamp focuses on minimizing the round trip to the server, client-side applications often work to limit the need for these trips altogether.

00:18:28.240 For every system architecture, it's vital to explore what each architecture is optimized towards.

00:18:42.880 I hypothesized that the server-side design aims to maintain consistency with the Rails programming style, allowing Rails developers to adapt to changes efficiently.

00:19:01.680 The Basecamp team has elegantly integrated this faster user responsiveness into Rails applications through minimal adjustments.

00:19:18.240 Client-side environments, unlike servers, have differentiated logic, allowing patterns while aiming to maintain simplicity.

00:19:32.560 I revisited the four applications discussed earlier to understand why we chose these architectures.

00:19:48.480 As I contemplated a new project and questioned whether to adopt the Basecamp or Discourse model, several things arose.

00:20:04.640 Firstly, consider whether the representation of the data remains stable. For example, are all users seeing essentially the same information?

00:20:19.360 The clarity from the Basecamp model deteriorates if different users see different information, complicating caching.

00:20:38.160 In my Ember application, which is map-based, the data representation changes significantly over time. My traditional application generally shows stable views.

00:20:58.960 In this latter case, it’s possible that the Basecamp structure provides more efficiency.

00:21:14.560 Next, determine if your client gives updates regarding data rather than requests. Consider a to-do list application where the data is locally available.

00:21:29.040 Once a task is completed, the client can update it first and later inform the server.

00:21:46.720 In contrast, a blogging engine needs frequent new data, as does something like Wikipedia when links are clicked.

00:22:00.560 This approach guides choices and should be examined, even if it’s difficult to categorize these situations precisely.

00:22:14.560 Next, reflect on whether the interactions between client components matter significantly. If client reactions are tied to each other, a framework like Ember is ideal.

00:22:30.560 Ember excels in allowing automatic updates in real-time as the user interacts with elements.

00:22:46.720 Another consideration is what resources you currently have. There are no style points for making hard decisions.

00:23:03.360 If you have programmers without JavaScript experience, introducing them to JavaScript during a new project is less effective. Minimization of new learning curves is key.

00:23:16.640 We chose Ember for a map project, allowing us to experiment without risking complete failure.

00:23:30.080 At the same time, I'm working on a Rails project with a pre-built application and a tight timeline, which reduces opportunities for risk.

00:23:47.680 Don't try to choose an unusual path that could impede your progress. Assess your environment and team readiness.

00:24:02.560 Hybrid approaches might also provide opportunities, as we've successfully combined Backbone with Rails in our Basecamp-style project.

00:24:17.600 We manage client-server interactions efficiently through JSON without needing a full client-side framework.

00:24:32.080 By using tools like Active Model Serializers, we're able to organize server-side logic without transmitting HTML to the client's side.

00:24:49.760 As we note, it’s vital to strike a balance between the server's processing and the client's responsiveness.

00:25:06.320 At this point in 2013, there should be no excuses for downloading assets repeatedly. By now, efficient caching and retrieval mechanisms should be in place.

00:25:23.680 I believe we are nearing the solution to efficient asset loading and maintenance in application development.

00:25:39.920 I predict that this conversation will continue to evolve in the coming year, particularly with JavaScript frameworks enhancing rapidly.

00:25:58.320 I have used Ember for a while and noticed great improvements. These improvements will pave the way for better web applications.

00:26:13.680 I envision a gradual decline in applications specifically tailored to the Basecamp approach as JavaScript framework efficiency continues to grow.

00:26:28.320 The tools will become increasingly capable, accommodating a broader range of applications.

00:26:35.440 I don't know if that renders a dramatic conclusion, but I appreciate your attention.

00:26:49.520 A couple of points to mention: I work at Table XI in Chicago, and you can follow us at tablexi.com.

00:27:04.000 I produce a weekly screencast called XY2I, discussing various topics related to development. You can check that out at its URL.

00:27:18.080 Additionally, my colleague Greg has a site called devpress.com, aimed at dealing with mental health issues in the development community.

00:27:32.320 If this resonates with you, please consider joining the community there.

00:27:46.080 You can also follow me on Twitter at @noelrap. I have a book titled 'Master Space and Time with JavaScript,' meant to improve your JavaScript skills.

00:28:00.000 The book covers various topics including testing, the JavaScript object model, Backbone, and Ember, and is available at noelrappin.com.

00:28:15.440 You can use the discount code RAILSCONF25 to get 25% off through Friday.

00:28:28.720 Thank you for your attention! I would be happy to take a couple of questions if anyone has them.

00:28:45.680 Thank you!

00:29:00.480 You.

RailsConf 2013