Noel Rappin
Rails Vs. The Client Side
#ruby-on-rails
#javascript
#client-side-rendering
#single-page-applications-spa
#ember
#caching
#e-commerce
Summarized using AI
Rails Vs. The Client Side
by Noel RappinThe 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.
Explore all talks recorded at RailsConf 2013
+89