SlideShare ist ein Scribd-Unternehmen logo
1 von 103
Downloaden Sie, um offline zu lesen
CUTTING THE FAT
When to use Ajax and when to reload
TIFFANY CONROY
@theophani

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.
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.
Last summer there was a conference called “Throne of JS”
The conference had a very specific premise:
“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.
“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.
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 benefit of Ajax? What is
the cost of using Ajax?
Frameworks help up to solve technical problems, but can we ever avoid those problems
entirely?
What to expect

First I’m going to define some terminology.
Then we examine the benefits 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.
What to expect
• Terminology

First I’m going to define some terminology.
Then we examine the benefits 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.
What to expect
• Terminology
• Benefits and costs of Ajax

First I’m going to define some terminology.
Then we examine the benefits 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.
What to expect
• Terminology
• Benefits and costs of Ajax
• A pragmatic approach

First I’m going to define some terminology.
Then we examine the benefits 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.
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.
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 …
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.
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.
In the second half of the 90s …
JavaScript

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

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

asynchronously, without reloading the whole page.
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.)
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.
Let’s look at an example using Facebook messages.
I start to type a reply.
In my reply, I enter a web address.
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.
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.
Ajax → maintains context

The web stopped being a collection of static web sites with fixed 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.
CONTEXT

What do I mean by “context”?
“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.
User
Profile

News
Feed

Store
Checkout

Slideshow

Some examples of different contexts could be:
user profile, 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.
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.
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.
✓

Multiple parts of the same workflow can all happen in the same context.
In this example, the context is filling 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.
✓

Same context
Multiple parts of the same workflow can all happen in the same context.
In this example, the context is filling 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.
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.
Then you need to define which components go together.
Then you need to define which components go together.
So when I say a context, I mean these different groupings of related bits organized into
meaningful groupings.
Designers need to understand, define 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.
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 benefits against the technical costs.
Designers need to understand, define 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.
Ajax → maintains context

So, Ajax allows us to maintain context for users.
Lots of Ajax → “Fat Client”

Web applications that use a lot of Ajax are sometimes called “fat client”
FAT vs THIN
What is a “fat” client?

What do we mean by a “fat client”.
How is it different from a “thin client”
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.
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.
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.
“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.
“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 define 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”.
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.
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.
back button

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.
back button

SINGLE-PAGE APPS
deep-linking

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.
back button

SINGLE-PAGE APPS
deep-linking
#! hash-bang

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.
JavaScript router
back button

SINGLE-PAGE APPS
deep-linking
#! hash-bang

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.
JavaScript router
back button

SINGLE-PAGE APPS
deep-linking
#! hash-bang
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.
JavaScript router
back button

SINGLE-PAGE APPS
frameworks
deep-linking
#! hash-bang
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.
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 **benefits** do we gain from using
it?
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 film, 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.
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 film, 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.
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 film, 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.
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 film, 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.
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 film, 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.
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 film, 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.
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”.
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”.
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”.
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”.
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”.
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”.
Design problems a
fat client solves:

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

• Continuous interaction

Let’s look again at the interaction design problems that a fat client can solve.
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.
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.
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.
Maintain context
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.
Maintain context
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.
Maintain context
Design problems a
fat client solves:

• Continuous interaction
• Transitions between contexts
• Incremental loading
Establish context

Let’s look again at the interaction design problems that a fat client can solve.
Ajax → controls context

Ajax allows us to establish and maintain the context for the user, without jarring reloads.
BUT …
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?
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
Most important
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
Most important
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
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.
Design problems a
fat client solves:

• Continuous interaction
• Transitions between contexts
• Incremental loading

So what benefit of Ajax is the least important?
-> Transitions between contexts
Design problems a
fat client solves:

• Continuous interaction
• Transitions between contexts
• Incremental loading
Least important

So what benefit of Ajax is the least important?
-> Transitions between contexts
Design problems a
fat client solves:

• Continuous interaction
• Transitions between contexts
• Incremental loading
Least important

So what benefit of Ajax is the least important?
-> Transitions between contexts
New context? → Reload!

When the user switches to a new context, the page can just be reloaded.
NO TRANSITIONS!?

What about transitions?
Transition are nice to have but not essential for most cases.
“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.
Case study: Github
On github.com: a profile is a context, the repo file-browser is a context, and each pull
request is one context, with page reloads in between.
On github.com: a profile is a context, the repo file-browser is a context, and each pull
request is one context, with page reloads in between.
As we saw, Github is a collection of single-page apps, one per context, with page reloads in
between.
AJAX vs RELOAD?

So, when should you use Ajax and when should you use reload?
Let’s recap:
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.
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 benefit vs cost does Ajax have at that interaction point? Can we afford the
cost? Where can we eliminate our need for Ajax?
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 benefit.
Lastly, for developers:
Does your framework
minimize your technical costs?

Does your framework help solve the design problems while minimizing the technical costs?
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 benefit, 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.
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 benefit, 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.
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 benefit, 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.
QUESTIONS?
and discussion
@theophani
speakerdeck.com/theophani/cutting-the-fat
THANKS!
All content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/

Weitere ähnliche Inhalte

Was ist angesagt?

Developing Java Web Applications
Developing Java Web ApplicationsDeveloping Java Web Applications
Developing Java Web Applicationshchen1
 
API Technical Writing
API Technical WritingAPI Technical Writing
API Technical WritingSarah Maddox
 
learn mvc project in 7 day
learn mvc project in 7 daylearn mvc project in 7 day
learn mvc project in 7 dayQuach Long
 
Building Desktop RIAs with PHP, HTML & Javascript in AIR
Building Desktop RIAs with PHP, HTML & Javascript in AIRBuilding Desktop RIAs with PHP, HTML & Javascript in AIR
Building Desktop RIAs with PHP, HTML & Javascript in AIRfunkatron
 
Unobtrusive JavaScript
Unobtrusive JavaScriptUnobtrusive JavaScript
Unobtrusive JavaScriptdaveverwer
 
Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...
Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...
Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...Gáspár Nagy
 
JOSA TechTalks - RESTful API Concepts and Best Practices
JOSA TechTalks - RESTful API Concepts and Best PracticesJOSA TechTalks - RESTful API Concepts and Best Practices
JOSA TechTalks - RESTful API Concepts and Best PracticesJordan Open Source Association
 
High Performance JavaScript (CapitolJS 2011)
High Performance JavaScript (CapitolJS 2011)High Performance JavaScript (CapitolJS 2011)
High Performance JavaScript (CapitolJS 2011)Nicholas Zakas
 
Usability in the GeoWeb
Usability in the GeoWebUsability in the GeoWeb
Usability in the GeoWebDave Bouwman
 
Developing, building, testing and deploying react native apps
Developing, building, testing and deploying react native appsDeveloping, building, testing and deploying react native apps
Developing, building, testing and deploying react native appsLeena N
 
Building single page applications
Building single page applicationsBuilding single page applications
Building single page applicationsSC5.io
 
Building Progressive Web Apps for Android and iOS
Building Progressive Web Apps for Android and iOSBuilding Progressive Web Apps for Android and iOS
Building Progressive Web Apps for Android and iOSFITC
 
AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...
AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...
AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...Bojan Veljanovski
 
Unobtrusive js
Unobtrusive jsUnobtrusive js
Unobtrusive jsbretticus
 
Developing iOS apps on your iPad with XCAB
Developing iOS apps on your iPad with XCABDeveloping iOS apps on your iPad with XCAB
Developing iOS apps on your iPad with XCABCarl Brown
 

Was ist angesagt? (20)

Ajax
Ajax Ajax
Ajax
 
Developing Java Web Applications
Developing Java Web ApplicationsDeveloping Java Web Applications
Developing Java Web Applications
 
API Technical Writing
API Technical WritingAPI Technical Writing
API Technical Writing
 
Mvc Training
Mvc TrainingMvc Training
Mvc Training
 
learn mvc project in 7 day
learn mvc project in 7 daylearn mvc project in 7 day
learn mvc project in 7 day
 
Building Desktop RIAs with PHP, HTML & Javascript in AIR
Building Desktop RIAs with PHP, HTML & Javascript in AIRBuilding Desktop RIAs with PHP, HTML & Javascript in AIR
Building Desktop RIAs with PHP, HTML & Javascript in AIR
 
Unobtrusive JavaScript
Unobtrusive JavaScriptUnobtrusive JavaScript
Unobtrusive JavaScript
 
Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...
Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...
Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow (BDDx L...
 
JOSA TechTalks - RESTful API Concepts and Best Practices
JOSA TechTalks - RESTful API Concepts and Best PracticesJOSA TechTalks - RESTful API Concepts and Best Practices
JOSA TechTalks - RESTful API Concepts and Best Practices
 
High Performance JavaScript (CapitolJS 2011)
High Performance JavaScript (CapitolJS 2011)High Performance JavaScript (CapitolJS 2011)
High Performance JavaScript (CapitolJS 2011)
 
Usability in the GeoWeb
Usability in the GeoWebUsability in the GeoWeb
Usability in the GeoWeb
 
JOSA TechTalks - Better Web Apps with React and Redux
JOSA TechTalks - Better Web Apps with React and ReduxJOSA TechTalks - Better Web Apps with React and Redux
JOSA TechTalks - Better Web Apps with React and Redux
 
Developing, building, testing and deploying react native apps
Developing, building, testing and deploying react native appsDeveloping, building, testing and deploying react native apps
Developing, building, testing and deploying react native apps
 
Building single page applications
Building single page applicationsBuilding single page applications
Building single page applications
 
Building Progressive Web Apps for Android and iOS
Building Progressive Web Apps for Android and iOSBuilding Progressive Web Apps for Android and iOS
Building Progressive Web Apps for Android and iOS
 
AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...
AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...
AngularJS + NancyFx + MongoDB = The best trio for ultimate SPA by Bojan Velja...
 
Intro to react_v2
Intro to react_v2Intro to react_v2
Intro to react_v2
 
Visual resume
Visual resumeVisual resume
Visual resume
 
Unobtrusive js
Unobtrusive jsUnobtrusive js
Unobtrusive js
 
Developing iOS apps on your iPad with XCAB
Developing iOS apps on your iPad with XCABDeveloping iOS apps on your iPad with XCAB
Developing iOS apps on your iPad with XCAB
 

Andere mochten auch

Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...
Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...
Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...Codemotion
 
Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...
Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...
Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...Codemotion
 
Vincenzo Chianese - REST, for real! - Codemotion Milan 2017
Vincenzo Chianese - REST, for real! - Codemotion Milan 2017Vincenzo Chianese - REST, for real! - Codemotion Milan 2017
Vincenzo Chianese - REST, for real! - Codemotion Milan 2017Codemotion
 
Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...
Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...
Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...Codemotion
 
Engineering Design for Facebook
Engineering Design for FacebookEngineering Design for Facebook
Engineering Design for FacebookCodemotion
 
Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...
Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...
Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...Codemotion
 
James Williams - Demystifying Constraint Layout - Codemotion Milan 2017
James Williams - Demystifying Constraint Layout - Codemotion Milan 2017James Williams - Demystifying Constraint Layout - Codemotion Milan 2017
James Williams - Demystifying Constraint Layout - Codemotion Milan 2017Codemotion
 
Matteo Valoriani - How Augment your Reality: different perspective on the Rea...
Matteo Valoriani - How Augment your Reality: different perspective on the Rea...Matteo Valoriani - How Augment your Reality: different perspective on the Rea...
Matteo Valoriani - How Augment your Reality: different perspective on the Rea...Codemotion
 
Lean@core lean startup e cloud- - Codemotion Rome 2015
Lean@core   lean startup e cloud- - Codemotion Rome 2015Lean@core   lean startup e cloud- - Codemotion Rome 2015
Lean@core lean startup e cloud- - Codemotion Rome 2015Codemotion
 
Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...
Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...
Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...Codemotion
 
Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017
Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017
Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017Codemotion
 
Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...
Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...
Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...Codemotion
 
Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...
Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...
Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...Codemotion
 
Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017
Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017
Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017Codemotion
 
Codemotion rome 2015 bluemix lab tutorial -- Codemotion Rome 2015
Codemotion rome 2015   bluemix lab tutorial -- Codemotion Rome 2015Codemotion rome 2015   bluemix lab tutorial -- Codemotion Rome 2015
Codemotion rome 2015 bluemix lab tutorial -- Codemotion Rome 2015Codemotion
 
Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...
Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...
Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...Codemotion
 

Andere mochten auch (20)

Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...
Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...
Gabriele Petronella - Mythical trees and where to find them - Codemotion Mila...
 
Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...
Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...
Massimo Bonanni - L'approccio ai microservizi secondo Service Fabric - Codemo...
 
9
99
9
 
Vincenzo Chianese - REST, for real! - Codemotion Milan 2017
Vincenzo Chianese - REST, for real! - Codemotion Milan 2017Vincenzo Chianese - REST, for real! - Codemotion Milan 2017
Vincenzo Chianese - REST, for real! - Codemotion Milan 2017
 
Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...
Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...
Demi Ben-Ari - Monitoring Big Data Systems Done "The Simple Way" - Codemotion...
 
6
66
6
 
Engineering Design for Facebook
Engineering Design for FacebookEngineering Design for Facebook
Engineering Design for Facebook
 
5
55
5
 
Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...
Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...
Claudio Carboni - ArcGIS platformthe foundation of your idea - Codemotion Mil...
 
James Williams - Demystifying Constraint Layout - Codemotion Milan 2017
James Williams - Demystifying Constraint Layout - Codemotion Milan 2017James Williams - Demystifying Constraint Layout - Codemotion Milan 2017
James Williams - Demystifying Constraint Layout - Codemotion Milan 2017
 
Matteo Valoriani - How Augment your Reality: different perspective on the Rea...
Matteo Valoriani - How Augment your Reality: different perspective on the Rea...Matteo Valoriani - How Augment your Reality: different perspective on the Rea...
Matteo Valoriani - How Augment your Reality: different perspective on the Rea...
 
Lean@core lean startup e cloud- - Codemotion Rome 2015
Lean@core   lean startup e cloud- - Codemotion Rome 2015Lean@core   lean startup e cloud- - Codemotion Rome 2015
Lean@core lean startup e cloud- - Codemotion Rome 2015
 
Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...
Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...
Tiffany Conroy - Remote device sign-in – Authenticating without a keyboard - ...
 
Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017
Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017
Gabriele Nocco - Massive distributed processing with H2O - Codemotion Milan 2017
 
Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...
Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...
Anna Makarudze - Django Girls: Inspiring women to fall in love with programmi...
 
Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...
Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...
Alberto Maria Angelo Paro - Isomorphic programming in Scala and WebDevelopmen...
 
Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017
Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017
Giovanni Laquidara - Hello ARCore - Codemotion Milan 2017
 
8
88
8
 
Codemotion rome 2015 bluemix lab tutorial -- Codemotion Rome 2015
Codemotion rome 2015   bluemix lab tutorial -- Codemotion Rome 2015Codemotion rome 2015   bluemix lab tutorial -- Codemotion Rome 2015
Codemotion rome 2015 bluemix lab tutorial -- Codemotion Rome 2015
 
Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...
Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...
Steve Sfartz - How to embed Messaging and Video in your apps - Codemotion Mil...
 

Ähnlich wie Cutting the Fat

Basics java scripts
Basics java scriptsBasics java scripts
Basics java scriptsch samaram
 
Building great mobile apps: Somethings you might want to know
Building great mobile apps: Somethings you might want to knowBuilding great mobile apps: Somethings you might want to know
Building great mobile apps: Somethings you might want to knowshwetank
 
What is java script
What is java scriptWhat is java script
What is java scriptsumanbaba_73
 
Spring Cloud Gateway - Nate Schutta
Spring Cloud Gateway - Nate SchuttaSpring Cloud Gateway - Nate Schutta
Spring Cloud Gateway - Nate SchuttaVMware Tanzu
 
Offline of web applications
Offline of web applicationsOffline of web applications
Offline of web applicationsFDConf
 
Offline for web - Frontend Dev Conf Minsk 2014
Offline for web - Frontend Dev Conf Minsk 2014Offline for web - Frontend Dev Conf Minsk 2014
Offline for web - Frontend Dev Conf Minsk 2014Jan Jongboom
 
Pablo Villalba -
Pablo Villalba - Pablo Villalba -
Pablo Villalba - .toster
 
Application Layer Protocol Called Hypertext Transfer...
Application Layer Protocol Called Hypertext Transfer...Application Layer Protocol Called Hypertext Transfer...
Application Layer Protocol Called Hypertext Transfer...Samantha Reed
 
Java script Basic
Java script BasicJava script Basic
Java script BasicJaya Kumari
 
WEB MODULE 3.pdf
WEB MODULE 3.pdfWEB MODULE 3.pdf
WEB MODULE 3.pdfDeepika A B
 
Java Script - A New Look
Java Script - A New LookJava Script - A New Look
Java Script - A New Lookrumsan
 
Synchronous Reads Asynchronous Writes RubyConf 2009
Synchronous Reads Asynchronous Writes RubyConf 2009Synchronous Reads Asynchronous Writes RubyConf 2009
Synchronous Reads Asynchronous Writes RubyConf 2009pauldix
 
Progressive Web Application by Citytech
Progressive Web Application by CitytechProgressive Web Application by Citytech
Progressive Web Application by CitytechRitwik Das
 
Essentials in JavaScript App Bundling with Webpack
Essentials in JavaScript App Bundling with WebpackEssentials in JavaScript App Bundling with Webpack
Essentials in JavaScript App Bundling with WebpackKhaled Al-Ansari
 
Presentation about html5 css3
Presentation about html5 css3Presentation about html5 css3
Presentation about html5 css3Gopi A
 
Phase 2 Case Study
Phase 2 Case StudyPhase 2 Case Study
Phase 2 Case StudyShannon Sand
 

Ähnlich wie Cutting the Fat (20)

Basics java scripts
Basics java scriptsBasics java scripts
Basics java scripts
 
Building great mobile apps: Somethings you might want to know
Building great mobile apps: Somethings you might want to knowBuilding great mobile apps: Somethings you might want to know
Building great mobile apps: Somethings you might want to know
 
What is java script
What is java scriptWhat is java script
What is java script
 
Spring Cloud Gateway - Nate Schutta
Spring Cloud Gateway - Nate SchuttaSpring Cloud Gateway - Nate Schutta
Spring Cloud Gateway - Nate Schutta
 
Offline of web applications
Offline of web applicationsOffline of web applications
Offline of web applications
 
Offline for web - Frontend Dev Conf Minsk 2014
Offline for web - Frontend Dev Conf Minsk 2014Offline for web - Frontend Dev Conf Minsk 2014
Offline for web - Frontend Dev Conf Minsk 2014
 
Pablo Villalba -
Pablo Villalba - Pablo Villalba -
Pablo Villalba -
 
Application Layer Protocol Called Hypertext Transfer...
Application Layer Protocol Called Hypertext Transfer...Application Layer Protocol Called Hypertext Transfer...
Application Layer Protocol Called Hypertext Transfer...
 
Javascript
JavascriptJavascript
Javascript
 
Java script Basic
Java script BasicJava script Basic
Java script Basic
 
WEB MODULE 3.pdf
WEB MODULE 3.pdfWEB MODULE 3.pdf
WEB MODULE 3.pdf
 
Java Script - A New Look
Java Script - A New LookJava Script - A New Look
Java Script - A New Look
 
Synchronous Reads Asynchronous Writes RubyConf 2009
Synchronous Reads Asynchronous Writes RubyConf 2009Synchronous Reads Asynchronous Writes RubyConf 2009
Synchronous Reads Asynchronous Writes RubyConf 2009
 
Progressive Web Application by Citytech
Progressive Web Application by CitytechProgressive Web Application by Citytech
Progressive Web Application by Citytech
 
Ajax Ppt 1
Ajax Ppt 1Ajax Ppt 1
Ajax Ppt 1
 
Essentials in JavaScript App Bundling with Webpack
Essentials in JavaScript App Bundling with WebpackEssentials in JavaScript App Bundling with Webpack
Essentials in JavaScript App Bundling with Webpack
 
Presentation about html5 css3
Presentation about html5 css3Presentation about html5 css3
Presentation about html5 css3
 
Phase 2 Case Study
Phase 2 Case StudyPhase 2 Case Study
Phase 2 Case Study
 
Ajax
AjaxAjax
Ajax
 
The mean stack
The mean stackThe mean stack
The mean stack
 

Mehr von Codemotion

Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Codemotion
 
Pompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyPompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyCodemotion
 
Pastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaPastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaCodemotion
 
Pennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserPennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserCodemotion
 
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Codemotion
 
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Codemotion
 
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Codemotion
 
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 - Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 - Codemotion
 
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Codemotion
 
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Codemotion
 
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Codemotion
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Codemotion
 
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Codemotion
 
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Codemotion
 
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Codemotion
 
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...Codemotion
 
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Codemotion
 
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Codemotion
 
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Codemotion
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Codemotion
 

Mehr von Codemotion (20)

Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
 
Pompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyPompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending story
 
Pastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaPastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storia
 
Pennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserPennisi - Essere Richard Altwasser
Pennisi - Essere Richard Altwasser
 
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
 
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
 
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
 
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 - Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
 
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
 
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
 
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
 
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
 
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
 
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
 
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
 
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
 
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
 
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
 

Kürzlich hochgeladen

Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 

Kürzlich hochgeladen (20)

Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 

Cutting the Fat

  • 1. CUTTING THE FAT When to use Ajax and when to reload
  • 2. TIFFANY CONROY @theophani 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.
  • 3. 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.
  • 4. Last summer there was a conference called “Throne of JS” The conference had a very specific premise:
  • 5. “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.
  • 6. “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.
  • 7. 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 benefit of Ajax? What is the cost of using Ajax? Frameworks help up to solve technical problems, but can we ever avoid those problems entirely?
  • 8. What to expect First I’m going to define some terminology. Then we examine the benefits 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.
  • 9. What to expect • Terminology First I’m going to define some terminology. Then we examine the benefits 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.
  • 10. What to expect • Terminology • Benefits and costs of Ajax First I’m going to define some terminology. Then we examine the benefits 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.
  • 11. What to expect • Terminology • Benefits and costs of Ajax • A pragmatic approach First I’m going to define some terminology. Then we examine the benefits 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.
  • 12. 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.
  • 13. 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 …
  • 14. 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.
  • 15. 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.
  • 16. In the second half of the 90s …
  • 17. JavaScript … after JavaScript was introduced, a JavaScript object called …
  • 18. JavaScript and XMLHttpRequest … XMLHttpRequest was introduced, which allowed content to be sent and loaded …
  • 20. 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.)
  • 21. 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.
  • 22. Let’s look at an example using Facebook messages.
  • 23. I start to type a reply.
  • 24. In my reply, I enter a web address.
  • 25. 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.
  • 26. 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.
  • 27. Ajax → maintains context The web stopped being a collection of static web sites with fixed 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.
  • 28. CONTEXT What do I mean by “context”?
  • 29. “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.
  • 30. User Profile News Feed Store Checkout Slideshow Some examples of different contexts could be: user profile, 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.
  • 31. 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.
  • 32. 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.
  • 33. ✓ Multiple parts of the same workflow can all happen in the same context. In this example, the context is filling 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.
  • 34. ✓ Same context Multiple parts of the same workflow can all happen in the same context. In this example, the context is filling 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.
  • 35. 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.
  • 36. Then you need to define which components go together.
  • 37. Then you need to define which components go together.
  • 38. So when I say a context, I mean these different groupings of related bits organized into meaningful groupings. Designers need to understand, define 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.
  • 39. 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 benefits against the technical costs.
  • 40. Designers need to understand, define 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.
  • 41. Ajax → maintains context So, Ajax allows us to maintain context for users.
  • 42. Lots of Ajax → “Fat Client” Web applications that use a lot of Ajax are sometimes called “fat client”
  • 43. FAT vs THIN What is a “fat” client? What do we mean by a “fat client”. How is it different from a “thin client”
  • 44. 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.
  • 45. 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.
  • 46. 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.
  • 47. “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.
  • 48. “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 define 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”.
  • 49. 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.
  • 50. 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.
  • 51. back button 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.
  • 52. back button SINGLE-PAGE APPS deep-linking 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.
  • 53. back button SINGLE-PAGE APPS deep-linking #! hash-bang 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.
  • 54. JavaScript router back button SINGLE-PAGE APPS deep-linking #! hash-bang 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.
  • 55. JavaScript router back button SINGLE-PAGE APPS deep-linking #! hash-bang 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.
  • 56. JavaScript router back button SINGLE-PAGE APPS frameworks deep-linking #! hash-bang 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.
  • 57. 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 **benefits** do we gain from using it?
  • 58. 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 film, 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.
  • 59. 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 film, 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.
  • 60. 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 film, 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.
  • 61. 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 film, 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.
  • 62. 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 film, 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.
  • 63. 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 film, 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.
  • 64. 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”.
  • 65. 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”.
  • 66. 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”.
  • 67. 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”.
  • 68. 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”.
  • 69. 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”.
  • 70. Design problems a fat client solves: Let’s look again at the interaction design problems that a fat client can solve.
  • 71. Design problems a fat client solves: • Continuous interaction Let’s look again at the interaction design problems that a fat client can solve.
  • 72. 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.
  • 73. 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.
  • 74. 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.
  • 75. Maintain context 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.
  • 76. Maintain context 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.
  • 77. Maintain context Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Establish context Let’s look again at the interaction design problems that a fat client can solve.
  • 78. Ajax → controls context Ajax allows us to establish and maintain the context for the user, without jarring reloads. BUT …
  • 79. 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?
  • 80. 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
  • 81. Most important 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
  • 82. Most important 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
  • 83. 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.
  • 84. Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading So what benefit of Ajax is the least important? -> Transitions between contexts
  • 85. Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Least important So what benefit of Ajax is the least important? -> Transitions between contexts
  • 86. Design problems a fat client solves: • Continuous interaction • Transitions between contexts • Incremental loading Least important So what benefit of Ajax is the least important? -> Transitions between contexts
  • 87. New context? → Reload! When the user switches to a new context, the page can just be reloaded.
  • 88. NO TRANSITIONS!? What about transitions? Transition are nice to have but not essential for most cases.
  • 89. “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.
  • 91. On github.com: a profile is a context, the repo file-browser is a context, and each pull request is one context, with page reloads in between.
  • 92. On github.com: a profile is a context, the repo file-browser is a context, and each pull request is one context, with page reloads in between.
  • 93. As we saw, Github is a collection of single-page apps, one per context, with page reloads in between.
  • 94. AJAX vs RELOAD? So, when should you use Ajax and when should you use reload? Let’s recap:
  • 95. 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.
  • 96. 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 benefit vs cost does Ajax have at that interaction point? Can we afford the cost? Where can we eliminate our need for Ajax?
  • 97. 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 benefit. Lastly, for developers:
  • 98. Does your framework minimize your technical costs? Does your framework help solve the design problems while minimizing the technical costs?
  • 99. 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 benefit, 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.
  • 100. 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 benefit, 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.
  • 101. 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 benefit, 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.
  • 103. THANKS! All content licensed under http://creativecommons.org/licenses/by-nc-sa/3.0/