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