00:00:28
Hello, I'm here today to talk about the real-time web. Needless to say, I've prepared a few slides. This is a pretty basic slide. It's a goat slide; it's a winning sports slide; it's the money slide.
00:00:39
My name is Aaron. I've been building websites since MySpace was cool. My band on tour needed custom profiles, and you could just inject JavaScript and CSS directly into their platform. We ended up making money selling it to other bands on tour, and that kind of inspired me to learn it and master the craft. Eventually, I moved to Colorado to help two friends grow a company to north of a million dollars in revenue. They sold it, and I started freelancing out of Galvanize in Denver, in their first location in the Golden Triangle.
00:01:10
I did some consultancy for a while building Ruby and Node apps. I also work in open source projects. Is anybody familiar with Susie, the grid framework for Sass? I played with that a lot and helped develop it. Now I'm in education at Galvanize, where I instruct at our Boulder location.
00:01:32
But before we dive into Ruby today, we need to start in the browser ecosystem. From the outside observer, it looks a lot like this: there's chaos. Every time you peek in, there's something new to see. Patrick has no idea what's going on — it's just cats everywhere, an absolute mess.
00:02:00
JavaScript got off to a bad start; granted, it was developed in just 11 days so it's a pretty impressive feat considering how ubiquitous it is in our ecosystem today. Meanwhile, it's improving with ECMAScript 6, which we've been talking about for a while now, and it's here. However, JavaScript still has its problems, and I know we've all felt that pain.
00:02:22
A lot of people see these issues and feel frustrated by it. I think it’s actually an inherent feature of the web. The reality is, none of us chose JavaScript; unlike Ruby, we chose the browser. Our users chose the browser, and as a consequence, we have a lot of different perspectives and ways to solve problems despite working with the exact same language and platform.
00:02:53
As a consequence, we have this massive diversity of solutions, and through iterations, we've seen new and innovative ways to solve problems and to keep up with users' expectations, which I want to spend some time talking about. If you haven’t read "The Dao of Web Design," I highly recommend it. To me, it boils down to the sentiment that new technology initially inherits the constraints of its predecessor.
00:03:29
We've seen this in every platform humans have invented to share media. With print for the first time, we were liberated from the constraints of time. We could communicate with people much farther in the future than we ever could before. With the radio, we could reach people who were otherwise disengaged — the blind or those occupied with driving. The TV introduced a visual context to the medium.
00:04:14
In each of these cases, we've seen these mediums inherit constraints of their predecessors. This was especially obvious with television, which for some time was referred to as 'radio with pictures.' Hosts would chat as if the audience couldn’t see the things they were describing — very obvious attributes of the people they were conversing with.
00:05:07
With the internet, like all other mediums, we have been liberated from many constraints. We're free from middlemen, allowing us to publish and participate as we please, yet we're still inheriting much from television and radio, but especially from print. The page metaphor has been said to be killing the web for some time now.
00:05:48
We're not working with pages; we're working with systems of components mapped to routes. We're not designing things above the fold, a concept inherited from marketing where everyone cared about what article was published in the top half of the newspaper since that was all people would see.
00:06:24
This strange language still defines how we work on the web, but it's broken. This was never more obvious than when the iPhone was invented. Suddenly, we had to adapt our views to different resolutions and contexts.
00:06:36
It's never been more true since we started to develop thick clients on top of our APIs. Today, I think applications are responsive, reactive, and real-time, according to both the technology we now have to build them and the user's expectations of how certain types of apps are expected to behave.
00:07:56
I'm going to go over each of these three points starting with responsiveness. You may be familiar with the big three points of responsive design: fluid layouts, flexible media, and media queries. Fluid layouts use percentage-based widths to adapt to any resolution; flexible media allows you to determine the density or weight of an image based on resolution; and media queries enable control based on resolution.
00:08:41
Ethan Marcotte changed things for us with that formula. However, one aspect that we’re not taking full advantage of, which I consider the fourth component of responsive design, is context. Resolution alone doesn't provide enough information. Imagine a scenario where your application can detect the current velocity of a user or that they're away from predefined geographical coordinates.
00:09:48
We possess that information in the browser and can utilize a number of other data points besides resolution to our advantage, and we can do that now. Then there's reactivity — a very engaging concept. The best example we have for it is a Google spreadsheet.
00:10:40
Reactivity can be defined as when a view re-renders because the underlying data changes. This isn't a new concept. For example, in a spreadsheet, if cell A equals B plus C and C changes, then the value of A updates accordingly. We see this in character counts on Twitter, which counts down as you approach 144 characters, and in spell-check while typing in the browser when the underlying data changes.
00:11:34
With reactivity comes reactive latency compensation — a method of enhancing user experience and making your app feel incredibly fast. Given that the network exhibits latency, it takes an uncertain amount of time for a transaction to occur. The optimal approach is to post user data to an in-memory representation of your database first. We have numerous implementations of this, and since views are bound to that in-memory data representation, they can re-render immediately.
00:12:41
This optimistic approach assumes that the user provided the information you need, and it will perform as expected before confirming the transaction over the network. Following that, you should validate and respond appropriately, effectively taking the usual time for this process, but well executed, the user navigates their application seamlessly.
00:13:32
As we build larger JavaScript clients on top of Rails APIs, performance and page speed become a focus. Metrics like page load time — how long it takes for the whole page to load — are important, and we should certainly consider that. Discussions of time to first paint were also heightened when Amazon demonstrated that getting anything on the screen, whether styled or unstyled, quickly increased their conversion rates by significant margins.
00:14:51
We also talk about above the fold paint, which I find quite trivial. The more critical perspective we need to adopt is the time to operate, the duration it takes for a user to make a decision about what to do next in your application. It's crucial to ensure that this time is minimized, as a blocking interface due to high painting time could not improve conversion rates.
00:15:35
A prime example of a site doing this well is Facebook. If you try to stop their page loading, they will display a UI preview with placeholders representing the general layout of the data. This way, even if the page doesn't render completely, you know where you're headed next. Furthermore, within the context of reactivity, there is also the element of online-offline state.
00:16:59
Users want to be sure that their data is up to date. For instance, Slack executes this exceptionally well. If you go offline while using their platform, they provide instant indicators that something is wrong, like a red 'x' and a yellow input field. They also notify you about attempts to reconnect. When reconnection fails, they queue your message for sending later with a note allowing users to click and retry while reminding them that their data might not yet be safe.
00:17:57
I love Twitter and respect what they're doing, but they haven’t fully addressed offline posting. If you are offline and attempt to tweet, you may receive an internal server error; a misguidance since you're not online. As we reflect on reactivity for real-time systems, typically, it involves delivering data over the wire, with the client capable of intelligently re-rendering views after data changes or as users navigate the interface.
00:19:44
This process enables numerous tools to support it. The key concept is data on the wire; you're not transferring HTML when submitting a form, only the data itself without full page refreshes, ensuring everything stays up to date. The real-time web has made our social apps more engaging, our utilities more effective, and our collaborative tools much more collaborative.
00:20:36
For instance, Google Docs exemplifies this well. I fondly recall the first time I experienced Gmail without needing to refresh, and watching search results populate under my feet as I typed was exhilarating. Speed is always a competitive advantage utilized across various businesses, though there are unique constraints and challenges when designing these applications.
00:21:53
The archetypal example of real-time applications would be a chat app. Later, I will demonstrate a chat application built with Rails 5, where Slack serves as a model. Chat platforms append new data to the bottom of the chat. However, developers must consider the overflow: do you scroll the viewport or leave it to the user? What if a user is reading older messages and has scrolled to the top?
00:23:02
Therefore, unique algorithms and problems arise. Twitter, meanwhile, prepends incoming data to their feed which is a clever approach, preventing interruption when users scroll through previous tweets since rendering occurs in batches and allows users to decide when rendering happens.
00:23:36
A crucial aspect to consider in real-time apps is progress retention, especially in emergencies. Eric Meyer, the inventor of CSS, has highlighted the importance of designing for crises. Progress retention enhances user confidence during urgent situations.
00:24:03
Imagine if a user fills out a request for emergency supplies during a Boulder flood. They shouldn’t need to hit submit right away; the application should reassure them that their data is being retained. Google Drive implements this well, showing users notifications like 'saving' after they input data.
00:25:10
Airbnb does this effectively, but their notification about saved data disappears quickly, leading to user uncertainty if they do not visually recall it. Ultimately, applications are increasingly burdened by the right-time web where distractions from unwanted notifications become a norm.
00:26:01
It's essential to batch notifications, delivering them once a day to find balance. Throughout this presentation, I've emphasized that while technology draws us closer to creating real-time defaults for many application types, we must exercise caution and recognize that such real-time capabilities aren't always necessary.
00:27:00
Today, apps are responsive as they've always been but infused with contextual awareness, reactivity, and real-time capabilities where applicable. I've been working with Meteor for some time, and many developers are successfully deploying it in production.
00:27:26
In Rails 5, we have Action Cable. Volt has long existed for those who use Opal to transpile Ruby into JavaScript. Rails has a unique approach here, which we can explore now.
00:27:50
There are several components to it; first, it uses Redis as a middleman in the system, particularly its pub/sub feature alongside WebSockets. When we consider real-time applications, there are three main competing approaches: long polling, short polling, and WebSockets. WebSockets are winning in many scenarios and Rails has rightfully integrated this into its ecosystem.
00:28:24
Rails has unique terminology for this, referred to as Action Cable. Action Cable indicates one socket per session. In any app, you can have multiple sessions, and each of these will have their individual WebSocket, with various resources that are real-time.
00:29:06
In the chat app we will explore built with Rails 5, we'll utilize a messages resource, or a messages channel, and then there's the broadcaster responsible for emitting events to anyone subscribed to specific channels on the socket.
00:29:31
Thank you for your attention. Let's see how these concepts are applied in practice.