Rich, modern web-applications are changing the way we write software for the Internet. As browsers grow evermore powerful, we become able to construct more complex and interactive applications by deferring some server-side logic to the client. In this presentation, we will establish a definition and characteristics for what makes web-applications modern and compare the benefits and trade-offs by exploring a few case studies. About the Author: Mike Filbin is a full-stack web developer who focuses on engineering JavaScript applications for both the browser and the server. Mike is also a proponent of the Free and Open Source software movements and is a member of both the Linux and Free Software foundations.

1. 1

2. • Who
here
considers
themselves
solely
a
backend
developer?
The
thought
of
wri<ng
HTML
makes
you
quizzy.
• Who
here
considers
themselves
a
front-­‐end
developer?
By
that
same
token,
SQL
statements
give
you
indiges<on.
• Anyone
here
consider
themselves
a
full-­‐stack
developer?
You
all
are
crazy,
I
like
you.
2

3. I
would
like
to
thank
Chris
Wallace.
Chris
thank
you
for
allow
us
to
be
here
tonight.
I’d
also
like
to
thank
MicrosoN
for
allowing
us
to
use
this
space
tonight
I
would
like
to
thank
Aspenware
for
sponsoring
this
event
and
for
providing
us
dinner
Who
from
Aspenware
is
in
the
audience
And
I
would
like
to
thank
all
of
you
for
sharing
your
aOen<on
with
me
3

4. 4

5. • Let’s
start
off
tonight’s
discussion
with
a
thought
provoking
quote
by
Ryan
Singer,
• I
want
to
offer
up
a
postulate
tonight
that
we
can
make
our
applica<ons
more
simple
by
just
changing
the
way
we
approach
architec<ng
them.
We
don’t
have
to
sacrifice
robustness
or
func<onality
and
instead
we
stand
to
gain
a
lot
from
modern
engineering
prac<ce
that
RWA
offer.
5

6. • The
term
Rich
Web
Applica<on
and
Rich
Internet
Applica<on
are
conflated
and
confused.
• The
idea
of
Rich
Internet
Applica<ons
was
coined
by
Adobe
(then
Macromedia)
when
introducing
their
Flex
applica<on
framework.
• Unlike
RIA
that
depend
upon
proprietary
file
formats,
language
subtypes,
and
run<mes,
RWA
center
around
a
common
set
of
open
and
standardized
web
technologies
• HTML
• JavaScript
(ECMA
Script)
• CSS
• Like
RIA,
RWA
execute
in
the
browser
with
the
intent
to
emulate
a
more
customary
desktop
(and
mobile)
experience.
• Today,
if
I
want
to
go
watch
a
movie
on
YouTube,
I
don’t
have
to
install
the
plugin
from
the
Adobe
website
first.
• More
restricted
than
RIAs
and
therefore
smaller
security
risk
for
distribu<ng
malware/viruses/Trojans.
• Zero-­‐day
exploits
6

7. • RWAs
are
synonymous
with
the
term
“Web
2.0”
(coined
by
Darcy
DiNucci
and
later
popularized
by
Tim
O’Reily
in
his
ar<cle
‘What
is
Web
2.0’)
• Web
2.0
really
represented
an
evolu<on
in
our
thinking
towards
the
way
we
engineered
soNware
for
the
world
wide
web
• Modern,
Rich
web
applica<ons
are
now
ubiquitous.
• There
was
a
<me
when
we
differen<ated
color
TV
from
black
and
white
–
color
TV
was
novel
and
exci<ng.
7

8. • The
types
of
applica<ons
that
we
are
building
today
are
very
much
like
the
early
Web
2.0
applica<ons
of
yesteryear,
except
that
we
are
changing
the
way
we
are
going
about
implemen<ng
them.
• For
a
<me,
there
was
a
need
for
these
technologies.
All
of
the
poten<al
uses
for
HTML
and
CSS
couldn’t
possibly
be
envisions,
so
plugins
were
created
to
fill
those
gaps
• We
are
learning
• Mobile
device
manufactures
don’t
want
to
have
to
deal
with
the
security
vulnerabili<es
• End-­‐user
don’t
want
to
have
to
manage
10’s
of
plugins
to
enjoy
the
Internet
8

9. • The
web
is
where
our
interests
are
• I
downloaded
the
graph
because
I
thought
it
was
interested
to
correlate
the
number
of
Stack
Overflow
posts
with
the
number
of
Github
deltas
• I
interpret
this
graph
to
represent
the
echo
system
of
modern
technology.
A
census
if
you
will.
9

10. 10

11. • What
we
recognize
as
the
Internet
and
the
World
Wide
Web
really
began
in
1991
when
Sir
Tim
Berners-­‐Less
invented
the
Hypertext
Transfer
Protocol
by
layering
TCP
over
DNS.
He
also
created
the
first
specifica<on
for
HTML.
These
two
tools
became
the
basis
for
ENQUIRE,
the
predecessor
to
the
World
Wide
Web.
A
card-­‐
based
system
that
allowed
CERN
researchers
to
share
their
findings.
• AOL
popularized
the
internet.
They
mailed
the
3x5
floppies
in
the
mail
to
thousands
of
people
world-­‐wide
• Search
engines
were
IMHO
the
catalysts.
This
meant
I
could
navigate
the
web
by
intent
–
I
didn’t
have
to
know
the
URL
for
the
thing
I
was
looking
for.
It
also
enabled
discovery,
• 1995
–
199g
was
the
birth
of
the
RIA
• HTML4
brought
a
scriptable
DOM
so
we
could
now
make
websites
more
‘interac<ve’
• MicrosoN
gave
us
XHR
–
perhaps
one
of
the
most
siginificant
and
probably
least
celebrated
contribu<on
to
the
modern
web.
11

12. • The
2000’s
saw
the
birth
of
the
RWA
• Applica<ons
like
Gmail,
Google
Maps,
and
MySpace
showed
us
that
web
was
could
be
empowered
without
the
plugin
• 2006
jQuery
revolu<onized
JavaScript.
• The
release
and
popularity
of
iOS
meant
the
death
of
Flash
• HTML5
and
TraceMonkey
the
first
JIT
sparked
a
new
browser
war
12

13. 13

14. • My
RWA
and
my
web
service
don’t
have
to
know
anything
about
one
another.
• Their
code
bases
can
evolve
completely
independently
(oNen
owned
by
other
teams)
• ONen
served
up
by
completely
separate
machines
• Backend
can
be
any
language
or
a
combina<on
there
of
• Because
the
applica<ons
live
of
different
machines
they
can
respond
independently
to
scaling
pressures
• Maybe
I
have
a
public
API
that
is
consumed
by
a
variety
of
clients.
I
may
need
more
API
machines
than
I
do
need
UI
machines
• Greater
modularity
of
client-­‐side
code.
• jQuery
taught
us
about
the
plugin
• Because
we
break
our
applica<on
apart
(meaning
the
logic
and
the
data)
we
can
shrink
the
send
less
over
the
wire
and
ask
for
only
what
we
need.
• I
don’t
have
to
no<fy
my
user
that
there
is
a
new
version
of
my
plugin
and
ask
them
to
download
it.
They
just
get
the
benefit
of
my
updates
by
visi<ng
my
site
–
for
free
• With
the
rise
of
popularity
of
Node.js,
companies
like
AirBnB
can
take
advantage
of
Isomorphic
JavaScript.
Meaning
I
can
share
code
that
executes
on
my
server
with
my
browser
client
to
reduce
redundency
• -­‐-­‐-­‐-­‐-­‐
Mee<ng
Notes
(12/9/13
12:19)
-­‐-­‐-­‐-­‐-­‐
• Snapper
spelling
mistake
14

15. 15

16. This
graph
trends
ac<vity
on
various
Open
Source
JavaScript
libraries
and
frameworks
over
the
last
few
years.
These
projects
are
each
racing
to
solve
the
same
problem
–
how
do
we
beOer
architect
and
organize
our
client-­‐side
JavaScript
applica<ons.
16

17. 17

18. Modern
Rich
Web
Applica<ons
now
assume
similar
architectural
paOerns
as
the
server-­‐side
applica<ons
many
of
us
our
use
to
working
with.
This
paradigm
shiN
away
from
jQuery
plugins
and
DOM
scrip<ng
has
enabled
us
to
write
cleaner,
testable,
and
more
portable
code
necessary
to
support
the
idea
of
a
browser-­‐based
applica<on.
18

19. 19

20. The
idea
of
a
rich,
browser
based
experience
was
not
only
borne
out
of
the
need
for
beOer
engineering
prac<ces,
but
also
supported
by
the
need
to
transi<on
away
from
the
heavy,
thick
clients
to
the
more
of
a
SaaS
business
model.
Installing
and
uninstalling
large
applica<ons
is
a
messy
business.
Empowering
business
people
to
reach
a
broader
audience
without
the
need
to
install
addi<onal
soNware
proved
to
be
a
very
profitable
model
for
many.
20

21. •
•
•
•
•
The
user’s
needs
are
more
qualita<ve.
Think
of
this
slide
as
Abraham
Maslow’s
hierarchy
of
needs
for
the
RWA
user.
Basic
needs
are
at
the
boOom
and
the
represent
the
essen<als
to
online
life
Higher-­‐order
needs
float
to
the
top
of
the
pyramid.
Because
there
are
numerous
op<ons
on
the
web
today,
the
higher
order
needs
are
the
differen<ators
of
success
21

22. 22

23. • Op<mizing
your
web
applica<on
does
become
more
challenging,
but
its
not
as
bad
as
you
think.
I’ve
posted
a
link
in
the
resources
sec<on
of
my
slides
to
help
you
along
the
way
• If
you
can’t
take
advantage
of
techniques
like
Isomorphic
JavaScript,
you
may
have
code
duplica<on
–
but
it
should
be
minimal.
Data
valida<ons
is
perhaps
the
most
common
case
• By
delega<ng
some
logic
to
the
client
you
will
raise
the
complexity,
but
I
that
isn’t
a
bad
thing.
By
separa<ng
the
responsibili<es
of
the
service
and
the
presenta<on
<er,
you
may
in
fact
find
a
new
reduc<on
in
overall
applica<on
complexity
• Cross-­‐Domain
limita<ons
of
browsers
are
quickly
becoming
a
thing
of
the
past.
There
are
beOer
ways
to
deal
with
JavaScript
applica<on
vulnerabili<es
like
cross-­‐
site
scrip<ng,
so
modern
browsers
now
allow
for
Cross-­‐Origin
Resesource
Sharing
which
allows
you
to
specific
addi<onal
HTTP
headers
to
loosen
these
limita<ons
• Perhaps
the
most
significant
of
the
challenges
has
to
do
memory
management.
JavaScript
has
always
had
garbage
collec<on,
but
JavaScript
also
has
closures.
There
is
a
risk
in
not
fully
understanding
scoping
in
JavaScript
that
could
lead
to
serious
memory
leaks
23

24. 24

25. 25

26. 26

27. 27

28. 28

29. 29

30. 30

31. 31