Rails is Obsolete (But So's Everything Else)

by Avi Bryant

The video titled "Rails is Obsolete (But So's Everything Else)" features Avi Bryant's talk at GoGaRuCo 2010, where he discusses the evolution of web applications since 2004 and questions the relevance of existing frameworks like Rails in the current landscape of web development.

Key points addressed in the video include:
- Changing Nature of Web Apps: In 2004, web applications operated mainly through HTML requests and responses, often requiring full page reloads. In contrast, modern applications leverage JavaScript heavily, with frameworks often receiving JSON responses instead of HTML.
- Examples of Modern Apps: Websites like Gmail, Twitter, and Google Instant Search showcase the new paradigm of asynchronous operations and client-side rendering, which offer faster user experiences compared to traditional multi-page setups.
- Outdated Framework Design: The design principles that drove the creation of Rails back in 2004 are now inadequate. The shift towards JavaScript frontend has shown that conventional Model-View-Controller (MVC) architectures may need a re-evaluation to accommodate the JavaScript-centric applications of today.
- Improved Performance: The advancements in JavaScript engines, especially due to browsers like Chrome, have significantly enhanced performance, suggesting that heavier computations can be shifted to the client side as opposed to server-side processing.
- Adaptation Needed: Bryant suggests that traditional web design patterns, including views and controllers, might need to be reconsidered, emphasizing the shift towards an API-first approach for web applications.
- Practical Solutions: He offers a technique to optimize user interface generation in JavaScript, combining speed and usability by minimizing reliance on the traditional DOM manipulation, which can be slow in certain browsers like Internet Explorer.
- Evolution Over Revolution: The talk underscores the importance of practical evolution in frameworks to meet the developing needs of web applications, urging developers to maintain user-centric design principles amid rapid technological changes.

In conclusion, Bryant advocates for a shift in thinking about web frameworks, arguing that while traditional concepts are not completely outdated, they must evolve to align with the realities of modern web development techniques that prioritize client-side performance and seamless user experiences.

00:00:04.500 Thank you.

00:00:10.330 This is an intentionally provocative title because I found that I have more fun in talks if they're at least half discussion, rather than just a lecture.

00:00:15.710 Here's the plan: I'm going to start out by making a statement, follow that up with a question, and then complete it with an entirely complete answer, all followed by heckling. My hope is to get through those first three things in about 15 minutes, leaving a full 15 minutes for heckling. If you guys do your jobs correctly, there will be a constant stream of heckling, and that would be much more fun.

00:00:28.430 So here’s the statement: web apps do not work the same way they did in 2004. If I were to describe how a web app works, I might say something like this: when you log in, your browser makes a request to the server, and it returns a response with a bunch of HTML. The browser then renders that HTML, which probably contains several anchor tags that become links. When the end user clicks on one of those links, it makes another request for that URL, and the browser gets back a whole bunch more HTML, rendering a new page. Is that approximately how you would describe how a web app works?

00:00:54.829 I mean, there's forms and stuff too, right? So, for the web apps that I build now, this is increasingly how it works. In 2010, many web apps operate quite differently. You make a request to the server, and you often get back a large wad of JavaScript along with very little HTML. That JavaScript then sits in the browser for the entire session.

00:01:06.590 You don’t typically click on a link that takes you to a different URL and returns a bunch of HTML; instead, you click on a link that triggers a JavaScript handler which fires off a background request. The server responds with a bunch of JSON, but you don’t have the kind of big URL structure of your app, at least not in a form that the server sees. You might change the URL in the location bar, but that’s done through location hashes after the hash in the URL.

00:01:25.340 For example, apps that work this way include the new Twitter, which just came out recently, Google Instant Search, a recent application, and Etherpad, which I built last year.

00:01:31.880 Gmail is one of the canonical examples of an app that operates this way. A lot of these apps aren't just more responsive; they fundamentally change how we approach web app development.

00:01:40.740 For instance, with Google Instant Search, you can’t imagine it being built as a traditional multi-page web app. The original Google search functioned more like a multi-page web app, as you were taken to a new URL each time you searched or went through the results. In that case, a new request was made in the browser, fully rendering the page.

00:01:58.590 Etherpad is a fantastic application that disappeared after being acquired by Google, though it still exists as open-source software. It’s an excellent tool for collaborative editing on the web, heavily relying on client-side JavaScript. Gmail could theoretically be built in another way, but it certainly feels much better and more responsive as it is. And yet, many of these applications wouldn't even be feasible in a traditional multi-page setup.

00:02:19.130 Taking new Twitter as an example, every time I interact with it, I'm making a request that returns JSON. Everything I do, every click, results in a new request for another JSON file. The entire time I use Twitter, it’s all about making requests for JSON. Check the URL: twitter.com is the main URL. There aren't other URLs that users see; everything happens in the background after the hash.

00:02:37.610 This is a fundamentally different way of developing web applications compared to what we are all likely used to. So, why do I bring up 2004? Because 2004 is when Basecamp and Rails were introduced.

00:02:49.310 At that time, the decisions made in designing Rails were created based on the web environment of that era, and they have persisted to this day. You can't change those fundamental design decisions without a complete overhaul, and when those decisions were conceived, we were working in a very different world.

00:03:06.060 In 2004, Google was also doing web apps differently. Gmail was launched that year and was revolutionary. The reason others hadn’t implemented such apps was that it was genuinely challenging. Google had the resources and determination to make it work, but few others followed suit, until now, when that landscape has drastically changed.

00:03:31.710 Several factors contributed to this shift. One was the introduction of jQuery, which eased a lot of the pain associated with cross-browser JavaScript development, making it easier to work with the DOM. Another factor that deserves special mention is the influence of Chrome, which has pushed the industry to better their JavaScript implementations.

00:03:49.090 It’s important to recognize that JavaScript was notably slow in 2004. All JavaScript implementations were sluggish, often slower than MRI executing dynamic languages today. Looking at this chart from the Language Shootout, we can see that the V8 JavaScript implementation in Chrome is up to a hundred times faster in some benchmarks compared to other implementations.

00:04:06.420 This speed change means you can think about transferring data between your web app and the browser. It is often actually faster to perform operations in the browser rather than on the server. If you’re engaged in heavy data manipulation or statistical analysis, you might end up performing better in JavaScript on the client rather than Ruby on the server.

00:04:25.300 It's fascinating to point out that Mozilla has a page where they track their JavaScript implementation metrics. This is an example of how Chrome has motivated the industry to improve the speed of JavaScript engines.

00:04:42.850 Now, the question arises: how should we change the design principles established in 2004, specifically for frameworks like Rails, to fit the 2010 web apps? As promised, I don't have a full answer. I have a partial piece of an answer that I hope can stimulate some interesting discussion.

00:05:06.170 If we consider the Model-View-Controller (MVC) framework: the notion of models is shifting; this is partly due to the new NoSQL approaches emerging. However, that discussion is outside the scope of this talk, so I'll focus on it briefly.

00:05:25.920 In the context of today's web apps, views are increasingly about 'no HTML'. These applications do involve HTML at some point, but the server-side frameworks aren't generating the HTML; they’re serving JSON instead. Therefore, the question becomes: what purpose do traditional view templates serve when what we want to present is a data structure rather than a formatted view?

00:05:50.760 Additionally, let's talk about controllers. If, for example, in a contemporary app like Twitter, the only user-visible URL is simply twitter.com, what is your routing structure? Where are all your controller actions?

00:06:05.910 You may have some API endpoints, but the traditional idea of clean URLs becomes irrelevant because the only URL users see is that one at the root. We might have to reconsider the entire framework structure.

00:06:20.320 We've essentially discarded the view concept in this new web development paradigm and arguably need to rethink controllers as well. This raises the question: how can we adapt our frameworks to better suit the new realities of web app development?

00:06:35.830 For a partial answer, I want to introduce one useful trick. Let’s imagine I have a model and I'm fetching a bunch of JSON from my server. Then, I would want to build a user interface on the client side. Traditionally, you might use templates for that.

00:06:54.050 However, the issue with templates is that they require you to marshal objects into text, which leads to all kinds of issues. If instead, we build the DOM elements directly in JavaScript, say, using jQuery, I can create the elements in a loop and attach handlers using closures. This way, when the handler is triggered, it can directly reference the item, removing the need for IDs or text representation and keeping the code clean and effective.

00:07:17.030 This approach lets you avoid repetitive lookups and keeps things simple. Yet, there’s a significant caveat: while all other browsers can handle DOM creations quickly without issue, Internet Explorer tends to fall flat in this respect.

00:07:43.239 If done in Internet Explorer, dynamically creating DOM elements tends to be excessively slow. So, unless you’re working under the assumption that none of your users will be on IE, this strategy could fall flat.

00:08:01.020 The workaround is this: while you can't manipulate the DOM quickly with IE, you can use inner HTML, which remains a fast option across all browsers. Here's the trick: as you create your elements, rather than creating DOM elements directly, you create small snippets of HTML.

00:08:16.020 Each time you need a handler, you generate a unique ID for each element. After assembling your document fragments and inserting them into the DOM via inner HTML, you can then associate the handlers with any elements that need them outside of the insertion process.

00:08:30.630 This allows you to harness both worlds: the speed of concatenating text with inner HTML while maintaining a clean JavaScript-based closure for your handlers. That’s my presentation for today, and I look forward to opening the floor for questions or any heckling.

00:09:00.080 I may have mentioned earlier that the solutions I've provided today are contributing to our understanding of these evolving web paradigms, but as we know, further answers are needed regarding frameworks like Sinatra.

00:09:13.420 I appreciate your feedback about Sammy. You've indicated it tries to introduce local hash routing for JavaScript, closely resembling Sinatra. Frankly, I'm uncertain of it and will need to explore its principles more thoroughly.

00:09:28.450 While I currently use Rails on the backend, I'm not using Active Record as that no longer seems necessary. This is a slow process as I seek to develop more meaningful answers. I'm gradually evolving my opinions on how these frameworks can integrate more effectively.

00:09:48.490 I was glad to come across your blog post announcing your transition to SproutCore; your citation of this talk emphasized important points. Meanwhile, we are all cognizant of the core argument that we need enhanced client-side answers.

00:10:05.650 Some might hold differing views regarding Rails. Though I recognize the efforts aimed at improving HTTP support, it’s clear we haven't fully addressed the changing landscape of web applications. Essential components are still dependent on the server-side such as authentication, etc.

00:10:25.590 Frameworks must continue to evolve beyond just Active Record and provide support for an API-based structure that acknowledges this transition. That will ensure we can deliver smooth experiences across platforms while accommodating various web application models.

00:10:45.640 The point you’re raising about whether the request-response lifecycle is obsolete is very much alive. While Active Record could become less relevant with numerous web services appearing, one must remember that having a structure capable of returning JSON in a request-response format remains essential.

00:11:05.000 Regarding the MVC model, I find that while controllers are not entirely obsolete, many design principles must be retired to accommodate parts most relevant to modern web development. That being said, we should not entirely discard clean URLs because their value remains, specifically in terms of user experience and discoverability.

00:11:35.060 Furthermore, any frameworks that are deprived of functionality are not appealing. I project that we should aim at constructing minimalistic designs while retaining capabilities that enhance elegance and usability. Therefore, it is important to reflect on how we can push the envelope with frameworks moving forward.

00:12:00.350 I believe that the discourse initiated here could potentially redefine outlooks within our community, and I appreciate all contributions to this topic.

00:12:30.490 Underlying all tech discussions, I encourage practical evolution rather than forceful revolutions. While it’s indeed necessary to discuss our capacity to bear these alterations, a measured resolution might be the key tool that we keep refined.

00:12:50.210 Additionally, it's vital to consider the SEO implications and initial page rendering when addressing these changes. A project known as Ruby Racer marries the V8 runtime with Ruby, allowing you to utilize server-side JavaScript capabilities.

00:13:10.030 This will permit server-based rendering of templates, ensuring that they're both SEO-friendly and usable by clients lacking JavaScript support. While the solutions are still limited, advancements in this area are promising.

00:13:30.710 On another note, I’d also like to highlight a project by a colleague that enables rack apps to bypass controllers and interact directly with models, returning JSON instead. This kind of lightweight structure empowers rich JavaScript clients while still utilizing Ruby on the server.

00:14:00.080 I’m curious: how many people here are currently developing applications in the styles we've discussed?

00:14:20.640 I reckon there’s significant interest in these approaches as we keep moving in that direction. However, there's still a pressing need for frameworks to support this emerging paradigm. Balancing this with legacy systems is critical.

00:14:40.590 At the same time, enterprise-level adoption retains some constraints owing to existing systems and user interfaces. As we progress towards embracing client-side improvements, it's crucial that we consider the longevity of established methodologies.

00:15:00.640 In conclusion, while we strive to broaden definitions of web application architecture, framing our end goals within realistic expectations will prepare us for transitions taking place across ecosystems. Thank you all for your attentiveness, and I look forward to any further discussions.

00:15:20.690 Thank you.