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.
