Cutting the fat - Speaker Deck

Slide 1

Slide 1 text

CUTTING THE FAT When to use Ajax and when to reload

Slide 2

Slide 2 text

@theophani TIFFANY CONROY All content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/ My name is Tiffany, and I work as an interaction designer and front-end developer at SoundCloud.

Slide 3

Slide 3 text

CUTTING THE FAT When to use Ajax and when to reload When to use Ajax and when to reload ======================= This is a talk about being pragmatic. This is a talk is about how to reduce the technical complexity of web applications. This talk is about using interaction design to help make the choice between using Ajax and reloading the page.

Slide 4

Slide 4 text

Last summer there was a conference called “Throne of JS” The conference had a very speciﬁc premise:

Slide 5

Slide 5 text

“Throne of JS … is … focused on answering the question on every web developer’s mind: “Throne of JS is […] focused on answering the question on every web developer's mind: which framework?” Yes: rich, interactive web applications are now commonplace. There are so many frameworks for building these rich client applications, and the debate among developers is which of these frameworks to use.

Slide 6

Slide 6 text

“Throne of JS … is … focused on answering the question on every web developer’s mind: which framework?” “Throne of JS is […] focused on answering the question on every web developer's mind: which framework?” Yes: rich, interactive web applications are now commonplace. There are so many frameworks for building these rich client applications, and the debate among developers is which of these frameworks to use.

Slide 7

Slide 7 text

Question the premise. The premise of the question “which framework” is based on the idea that in a modern web application, the page should never be reloaded. But as designers and developers, we need to step back, and ask ourselves: why don’t we want to reload the page? When *can* we reload the page, and What is the beneﬁt of Ajax? What is the cost of using Ajax? Frameworks help up to solve technical problems, but can we ever avoid those problems entirely?

Slide 8

Slide 8 text

What to expect First I’m going to deﬁne some terminology. Then we examine the beneﬁts and problems of fancy single-page web applications. Lastly, I want to show you one way of approaching your applications as a designer and developer that can help you reduce complexity, even before you choose a framework. Let’s get started.

Slide 9

Slide 9 text

What to expect • Terminology First I’m going to deﬁne some terminology. Then we examine the beneﬁts and problems of fancy single-page web applications. Lastly, I want to show you one way of approaching your applications as a designer and developer that can help you reduce complexity, even before you choose a framework. Let’s get started.

Slide 10

Slide 10 text

What to expect • Terminology • Benefits and costs of Ajax First I’m going to deﬁne some terminology. Then we examine the beneﬁts and problems of fancy single-page web applications. Lastly, I want to show you one way of approaching your applications as a designer and developer that can help you reduce complexity, even before you choose a framework. Let’s get started.

Slide 11

Slide 11 text

What to expect • Terminology • Benefits and costs of Ajax • A pragmatic approach First I’m going to deﬁne some terminology. Then we examine the beneﬁts and problems of fancy single-page web applications. Lastly, I want to show you one way of approaching your applications as a designer and developer that can help you reduce complexity, even before you choose a framework. Let’s get started.

Slide 12

Slide 12 text

AJAX vs RELOAD A quick recap for everyone on what Ajax is and what we use it for, and how it differs from a page reload.

Slide 13

Slide 13 text

In the early 90s, all web pages were static, and if you wanted to see new content, you followed a link or clicked on a form submit button …

Slide 14

Slide 14 text

In the early 90s, all web pages were static, and if you wanted to see new content, you followed a link or clicked on a form submit button … … and the whole page would reload.

Slide 15

Slide 15 text

Whole page reloads In the early 90s, all web pages were static, and if you wanted to see new content, you followed a link or clicked on a form submit button … … and the whole page would reload.

Slide 16

Slide 16 text

In the second half of the 90s …

Slide 17

Slide 17 text

JavaScript … after JavaScript was introduced, a JavaScript object called …

Slide 18

Slide 18 text

JavaScript and XMLHttpRequest … XMLHttpRequest was introduced, which allowed content to be sent and loaded …

Slide 19

Slide 19 text

Asynchronous JavaScript and XMLHttpRequest asynchronously, without reloading the whole page.

Slide 20

Slide 20 text

Asynchronous JavaScript and XMLHttpRequest In 2005, the technique of loading content asynchronously with JavaScript was given the name Ajax. Around that time Google released Gmail and Google Maps. (ps to big know-it-alls reading these speaker notes: yes, I know the X originally stood for XML, but making that distinction would just complicate things.)

Slide 21

Slide 21 text

Just one part reloads Ajax allowed us to change the page content without a full page reload. But the more exciting use case was to make the page send and load content based on user interaction.

Slide 22

Slide 22 text

Let’s look at an example using Facebook messages.

Slide 23

Slide 23 text

I start to type a reply.

Slide 24

Slide 24 text

In my reply, I enter a web address.

Slide 25

Slide 25 text

Without me doing anything, and without interrupting me typing, the Facebook app uses Ajax to load information about the link I entered, and adds it to my message.

Slide 26

Slide 26 text

When I send the message, the app uses Ajax to send my message without reloading the page. Ajax allowed us to maintain the context of what the user was doing, without reloading the page.

Slide 27

Slide 27 text

Ajax → maintains context The web stopped being a collection of static web sites with ﬁxed content, and allowed us to exchange data with the web server without reloading the page. Now, we rely heavily on Ajax to control the user's experience. To reiterate what I said before: Ajax allows us to maintain the context of what the user was doing, without reloading the page.

Slide 28

Slide 28 text

CONTEXT What do I mean by “context”?

Slide 29

Slide 29 text

“Context” is the answer to the question: where are you, and what are you doing. By this I am not talking about where you physically are while using a web application, but where you are *within* the web application, and what you are doing there.

Slide 30

Slide 30 text

User Profile News Feed Store Checkout Slideshow Some examples of different contexts could be: user proﬁle, a news feed, the checkout of a store, a slideshow. Within each of these contexts, we may not want to reload the page. Each distinct context could be its own “single-page app”, and a plain old browser refresh could be used to transition between these contexts.

Slide 31

Slide 31 text

But two different instances of the same “screen” are in fact two different contexts. For example: The timeline of two different people are two different contexts.

Slide 32

Slide 32 text

Two separate contexts But two different instances of the same “screen” are in fact two different contexts. For example: The timeline of two different people are two different contexts.

Slide 33

Slide 33 text

✓ Multiple parts of the same workﬂow can all happen in the same context. In this example, the context is ﬁlling out a form. While the user is in this context, we want to control the user’s experience as much as possible, so that the user doesn’t lose context.

Slide 34

Slide 34 text

✓ Same context Multiple parts of the same workﬂow can all happen in the same context. In this example, the context is ﬁlling out a form. While the user is in this context, we want to control the user’s experience as much as possible, so that the user doesn’t lose context.

Slide 35

Slide 35 text

Your application may have lots of little components and features and bits of information, and you need to understand out how they all relate to each other.

Slide 36

Slide 36 text

Then you need to deﬁne which components go together.

Slide 37

Slide 37 text

Then you need to deﬁne which components go together.

Slide 38

Slide 38 text

So when I say a context, I mean these different groupings of related bits organized into meaningful groupings. Designers need to understand, deﬁne and communicate the distinct contexts in any rich web application, being clear about the where boundaries between contexts are; where one stops and the next one starts.

Slide 39

Slide 39 text

When we make a transition from one context to the next, we exit the boundary of one context and enter another. Ajax could be used to control the transition between contexts, if the designer and the developer can negotiate it by balancing the beneﬁts against the technical costs.

Slide 40

Slide 40 text

Designers need to understand, deﬁne and communicate the distinct contexts in any rich web application, being clear about the where boundaries between contexts are; where one stops and the next one starts.

Slide 41

Slide 41 text

Ajax → maintains context So, Ajax allows us to maintain context for users.

Slide 42

Slide 42 text

Lots of Ajax → “Fat Client” Web applications that use a lot of Ajax are sometimes called “fat client”

Slide 43

Slide 43 text

FAT vs THIN What is a “fat” client? What do we mean by a “fat client”. How is it different from a “thin client”

Slide 44

Slide 44 text

Client = code in the browser SERVER ----[ network ]----> CLIENT ## Server and client In this discussion, the code that runs in a web browser is the “client”, in contrast with code that runs on a web server.

Slide 45

Slide 45 text

Thin client DATA + ALL THE LOGIC -------------------[ network ]----------------> PRESENTATION ## Thin Client [ DATA ] + [ ALL THE LOGIC ] ----[network]----> [PRESENTATION] All the logic is performed on the server-side. Static pages that rely on page reload are THIN. The browser, AKA the client, just displays the content.

Slide 46

Slide 46 text

Fat client DATA -------------------[ network ]----------------> ALL THE LOGIC + PRESENTATION ## Fat Client [ DATA ] + [ ALL THE LOGIC ] ----[network]----> [PRESENTATION] All the logic is performed on the client-side. The server sends static content over the network, and all the logic is done in the browser AKA the client. These fat clients rely on a lot of JavaScript and Ajax.

Slide 47

Slide 47 text

“Native Experience” People also talk about a “native experience” on the web. Ajax allows us to emulate a “native experience” on the web, meaning, it feels like an application not a web site.

Slide 48

Slide 48 text

“Native Experience” and controlling transitions One of the most basic features of a ”native” experience is the controlled transitions between contexts, for example, the sliding left and right between screens. On the web, if you reload the page, you can’t deﬁne the transition. In every browser I’ve used, the transition is the same: the page goes white, the spinner spins, and then the page loads. Reloading can be jarring. We can get around this if we load the content with Ajax, and then transition to the new context. We call these sort of sites that exclusively use Ajax “single-page apps”.

Slide 49

Slide 49 text

SINGLE-PAGE APPS Awesome or not awesome? So called “single-page apps” are very sexy these days. But people have begun to see that single-page apps are also nasty beasts that bring all sorts of technical complications with them.

Slide 50

Slide 50 text

SINGLE-PAGE APPS Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 51

Slide 51 text

SINGLE-PAGE APPS back button Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 52

Slide 52 text

SINGLE-PAGE APPS deep-linking back button Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 53

Slide 53 text

SINGLE-PAGE APPS deep-linking #! hash-bang back button Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 54

Slide 54 text

SINGLE-PAGE APPS deep-linking JavaScript router #! hash-bang back button Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 55

Slide 55 text

SINGLE-PAGE APPS deep-linking JavaScript router #! hash-bang back button window.history Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 56

Slide 56 text

SINGLE-PAGE APPS deep-linking JavaScript router #! hash-bang back button frameworks window.history Trying to recreate a native experience brings with it all kinds of technical problems. One upon a time, if the URL in the browser changed, the page reloaded. As we made rich applications using Ajax, we ran into the problem that we could reach a state in the application that we could not link to. We started to talk about how to “deep-link” to a context within an application. This wasn’t (usually) a problem before we started using Ajax.

Slide 57

Slide 57 text

Let’s pause for a moment: Why do we want to use Ajax? What problems are we trying to solve with Ajax? i.e. what **beneﬁts** do we gain from using it?

Slide 58

Slide 58 text

Problems a fat client solves: Problems a fat client solves: * The user can continue to interact (including simply viewing) while data is exchanged. * The designer can customize and control the loading and transition experience between contexts. * Information can be presented in a partial, incremental, incomplete form, thus context can be established while further information is retrieved. (Like a pan in a ﬁlm, setting can be established in advance of details.) * The traffic between server and client can be reduced to data separate from the presentation, reducing network use and speeding up information transmission. Most of these are design problems. Even improved speed would result in a better experience for people.

Slide 59

Slide 59 text

Problems a fat client solves: • Continuous interaction Problems a fat client solves: * The user can continue to interact (including simply viewing) while data is exchanged. * The designer can customize and control the loading and transition experience between contexts. * Information can be presented in a partial, incremental, incomplete form, thus context can be established while further information is retrieved. (Like a pan in a ﬁlm, setting can be established in advance of details.) * The traffic between server and client can be reduced to data separate from the presentation, reducing network use and speeding up information transmission. Most of these are design problems. Even improved speed would result in a better experience for people.

Slide 60

Slide 60 text

Problems a fat client solves: • Continuous interaction • Transitions between contexts Problems a fat client solves: * The user can continue to interact (including simply viewing) while data is exchanged. * The designer can customize and control the loading and transition experience between contexts. * Information can be presented in a partial, incremental, incomplete form, thus context can be established while further information is retrieved. (Like a pan in a ﬁlm, setting can be established in advance of details.) * The traffic between server and client can be reduced to data separate from the presentation, reducing network use and speeding up information transmission. Most of these are design problems. Even improved speed would result in a better experience for people.

Slide 61

Slide 61 text

Problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Problems a fat client solves: * The user can continue to interact (including simply viewing) while data is exchanged. * The designer can customize and control the loading and transition experience between contexts. * Information can be presented in a partial, incremental, incomplete form, thus context can be established while further information is retrieved. (Like a pan in a ﬁlm, setting can be established in advance of details.) * The traffic between server and client can be reduced to data separate from the presentation, reducing network use and speeding up information transmission. Most of these are design problems. Even improved speed would result in a better experience for people.

Slide 62

Slide 62 text

Problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading • Reduced network traffic Problems a fat client solves: * The user can continue to interact (including simply viewing) while data is exchanged. * The designer can customize and control the loading and transition experience between contexts. * Information can be presented in a partial, incremental, incomplete form, thus context can be established while further information is retrieved. (Like a pan in a ﬁlm, setting can be established in advance of details.) * The traffic between server and client can be reduced to data separate from the presentation, reducing network use and speeding up information transmission. Most of these are design problems. Even improved speed would result in a better experience for people.

Slide 63

Slide 63 text

Problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading • Reduced network traffic → DESIGN PROBLEMS (mostly) Problems a fat client solves: * The user can continue to interact (including simply viewing) while data is exchanged. * The designer can customize and control the loading and transition experience between contexts. * Information can be presented in a partial, incremental, incomplete form, thus context can be established while further information is retrieved. (Like a pan in a ﬁlm, setting can be established in advance of details.) * The traffic between server and client can be reduced to data separate from the presentation, reducing network use and speeding up information transmission. Most of these are design problems. Even improved speed would result in a better experience for people.

Slide 64

Slide 64 text

Problems a fat client causes: Problems a fat client causes: * Routing becomes the responsibility of the client-side script instead of the browser --> deep-linking * History management becomes the responsibility of the client-side script instead of the browser --> back button * Caching (what and for how long) becomes the responsibility of the client-side script instead of the browser --> reusing previously-fetched data and templates to achieve improved speed * Improvements from the speedy transmission are eroded by computation within the client i.e. instead of doing computation in an environment we can control (the server) we push it to the client, which is notoriously out of our control. These are technical problems. From a design perspective, these become trade-offs that are “someone else’s problem”.

Slide 65

Slide 65 text

Problems a fat client causes: • Routing Problems a fat client causes: * Routing becomes the responsibility of the client-side script instead of the browser --> deep-linking * History management becomes the responsibility of the client-side script instead of the browser --> back button * Caching (what and for how long) becomes the responsibility of the client-side script instead of the browser --> reusing previously-fetched data and templates to achieve improved speed * Improvements from the speedy transmission are eroded by computation within the client i.e. instead of doing computation in an environment we can control (the server) we push it to the client, which is notoriously out of our control. These are technical problems. From a design perspective, these become trade-offs that are “someone else’s problem”.

Slide 66

Slide 66 text

Problems a fat client causes: • Routing • History Problems a fat client causes: * Routing becomes the responsibility of the client-side script instead of the browser --> deep-linking * History management becomes the responsibility of the client-side script instead of the browser --> back button * Caching (what and for how long) becomes the responsibility of the client-side script instead of the browser --> reusing previously-fetched data and templates to achieve improved speed * Improvements from the speedy transmission are eroded by computation within the client i.e. instead of doing computation in an environment we can control (the server) we push it to the client, which is notoriously out of our control. These are technical problems. From a design perspective, these become trade-offs that are “someone else’s problem”.

Slide 67

Slide 67 text

Problems a fat client causes: • Routing • History • Caching and garbage collection Problems a fat client causes: * Routing becomes the responsibility of the client-side script instead of the browser --> deep-linking * History management becomes the responsibility of the client-side script instead of the browser --> back button * Caching (what and for how long) becomes the responsibility of the client-side script instead of the browser --> reusing previously-fetched data and templates to achieve improved speed * Improvements from the speedy transmission are eroded by computation within the client i.e. instead of doing computation in an environment we can control (the server) we push it to the client, which is notoriously out of our control. These are technical problems. From a design perspective, these become trade-offs that are “someone else’s problem”.

Slide 68

Slide 68 text

Problems a fat client causes: • Routing • History • Caching and garbage collection • Computation is outside of our control Problems a fat client causes: * Routing becomes the responsibility of the client-side script instead of the browser --> deep-linking * History management becomes the responsibility of the client-side script instead of the browser --> back button * Caching (what and for how long) becomes the responsibility of the client-side script instead of the browser --> reusing previously-fetched data and templates to achieve improved speed * Improvements from the speedy transmission are eroded by computation within the client i.e. instead of doing computation in an environment we can control (the server) we push it to the client, which is notoriously out of our control. These are technical problems. From a design perspective, these become trade-offs that are “someone else’s problem”.

Slide 69

Slide 69 text

Problems a fat client causes: • Routing • History • Caching and garbage collection • Computation is outside of our control → TECHNICAL PROBLEMS Problems a fat client causes: * Routing becomes the responsibility of the client-side script instead of the browser --> deep-linking * History management becomes the responsibility of the client-side script instead of the browser --> back button * Caching (what and for how long) becomes the responsibility of the client-side script instead of the browser --> reusing previously-fetched data and templates to achieve improved speed * Improvements from the speedy transmission are eroded by computation within the client i.e. instead of doing computation in an environment we can control (the server) we push it to the client, which is notoriously out of our control. These are technical problems. From a design perspective, these become trade-offs that are “someone else’s problem”.

Slide 70

Slide 70 text

Design problems a fat client solves: Let’s look again at the interaction design problems that a fat client can solve.

Slide 71

Slide 71 text

Design problems a fat client solves: • Continuous interaction Let’s look again at the interaction design problems that a fat client can solve.

Slide 72

Slide 72 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts Let’s look again at the interaction design problems that a fat client can solve.

Slide 73

Slide 73 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Let’s look again at the interaction design problems that a fat client can solve.

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Maintain context Let’s look again at the interaction design problems that a fat client can solve.

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Maintain context Establish context Let’s look again at the interaction design problems that a fat client can solve.

Slide 78

Slide 78 text

Ajax → controls context Ajax allows us to establish and maintain the context for the user, without jarring reloads. BUT …

Slide 79

Slide 79 text

Ajax → adds complexity Ajax also introduces all lot of technical complications. This is complication that you as designer don’t have to think about, but creates a lot of extra work for developers. And that extra work might not be worth it. How can designers help developers be pragmatic about when to use Ajax and when not to?

Slide 80

Slide 80 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading When we look at the problems that a fat client can solve, we can ask which one is the most important? -> Continuous interaction is the primary reason we use Ajax. We use it during form validation, live chatting, commenting while watching a video

Slide 81

Slide 81 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Most important When we look at the problems that a fat client can solve, we can ask which one is the most important? -> Continuous interaction is the primary reason we use Ajax. We use it during form validation, live chatting, commenting while watching a video

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Continuous interaction Continuous interaction is the primary reason we use Ajax. We use it during form validation, live chatting, commenting while watching a video, performing a search.

Slide 84

Slide 84 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading So what beneﬁt of Ajax is the least important? -> Transitions between contexts

Slide 85

Slide 85 text

Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Least important So what beneﬁt of Ajax is the least important? -> Transitions between contexts

Slide 86

Slide 86 text

Slide 87

Slide 87 text

New context? → Reload! When the user switches to a new context, the page can just be reloaded.

Slide 88

Slide 88 text

NO TRANSITIONS!? What about transitions? Transition are nice to have but not essential for most cases.

Slide 89

Slide 89 text

“The cool kids are doing it!” You might say: BUT BUT BUT … all the cool kids are doing it! My product is also cool! Maybe, but some of the cool kids still use page reload.

Slide 90

Slide 90 text

Case study: Github

Slide 91

Slide 91 text

On github.com: a proﬁle is a context, the repo ﬁle-browser is a context, and each pull request is one context, with page reloads in between.

Slide 92

Slide 92 text

On github.com: a proﬁle is a context, the repo ﬁle-browser is a context, and each pull request is one context, with page reloads in between.

Slide 93

Slide 93 text

As we saw, Github is a collection of single-page apps, one per context, with page reloads in between.

Slide 94

Slide 94 text

AJAX vs RELOAD? So, when should you use Ajax and when should you use reload? Let’s recap:

Slide 95

Slide 95 text

Limit your demand for Ajax Limit your demand for asynchronous communication to only within the contexts that matter. Only use it when you can afford it. “Single-page apps” are often made as single-page apps for the wrong reasons. I have made this mistake. Where is our need for Ajax? -- at the interaction points.

Slide 96

Slide 96 text

Find the interaction points Find the interaction points. Everywhere the user will click, type, hover or otherwise engage with the interface. For each, ask: what beneﬁt vs cost does Ajax have at that interaction point? Can we afford the cost? Where can we eliminate our need for Ajax?

Slide 97

Slide 97 text

Find the context boundaries Know where the boundaries between contexts are, and communicate them to developers, because these are important for designing the application architecture. Using Ajax in at these interaction points give us the least beneﬁt. Lastly, for developers:

Slide 98

Slide 98 text

Does your framework minimize your technical costs? Does your framework help solve the design problems while minimizing the technical costs?

Slide 99

Slide 99 text

Single-page apps? YES: we can help our users maintain context so they can focus without jarring interruptions. These means: use Ajax for each context, and each of those is its own single-page app. Monolithic apps? NO: or at least, they aren’t nearly as useful as they are technically hard, and you should be very clear of the costs. You may get so much beneﬁt, or have so many people working in the problems, that you can overcome the costs. Your *entire web app* does *not* need to be one single front-end app.

Slide 100

Slide 100 text

Single-page apps? → YES Single-page apps? YES: we can help our users maintain context so they can focus without jarring interruptions. These means: use Ajax for each context, and each of those is its own single-page app. Monolithic apps? NO: or at least, they aren’t nearly as useful as they are technically hard, and you should be very clear of the costs. You may get so much beneﬁt, or have so many people working in the problems, that you can overcome the costs. Your *entire web app* does *not* need to be one single front-end app.

Slide 101

Slide 101 text

Single-page apps? → YES Monolithic apps? → NO Single-page apps? YES: we can help our users maintain context so they can focus without jarring interruptions. These means: use Ajax for each context, and each of those is its own single-page app. Monolithic apps? NO: or at least, they aren’t nearly as useful as they are technically hard, and you should be very clear of the costs. You may get so much beneﬁt, or have so many people working in the problems, that you can overcome the costs. Your *entire web app* does *not* need to be one single front-end app.

Slide 102

Slide 102 text

QUESTIONS? and discussion @theophani speakerdeck.com/theophani/cutting-the-fat

Slide 103

Slide 103 text

THANKS! All content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/