A talk I gave at Codebits 2011. You can find the video here: https://codebits.eu/intra/s/session/204 Abstract: There's an abundance of talks about developing for the web. Most of it targeted to developing mass-market websites, worrying about CDNs, SEO, bookmarks, progressive enhancement, etc. But what if you want to build fullblown applications that just happen to be implemented in web technologies? Web apps, especially single-page, highly interactive ones, have some special characteristics. For a long time we've been implementing web apps as if the browser was a mostly dumb terminal, and instead kept most of the logic on the server. Even current favorits like RoR or GWT keep to that old paradigm. We'll see how we can take a REST architecture, combining it with a good dose of javascript MVP to create applications that are much closer, both in structure and in functionality, to desktop apps than to normal webpages. By fully embracing web technology, instead of "hiding" behind some leaky abstractions, we'll be set free to take our apps to the next level. And we'll see how much nicer they are to develop.

1. REST
+JS
the future for
highly interactive
web apps?

2. The case for
a new (ish)
Web App
style

3. The Evolution
of WebApps

4. static
html

5. dynamically
generated
static html pages

6. generated
bits of html
with some
javascript for "moving
things around"

7. What do those
have in common?

8. Most of the work
is done on the
server

9. Does this
make
sense?

10. State of the art MVC
frameworks
where the M
the C
and even the V
are server side concepts?

11. Maybe it did
before

12. But now...

13. HTML+CSS gives us a very
capable presentation
technology
and it gets more powerful
everyday

14. Javascript, well...everybody
loves it now

15. The browsers
even those from Redmond
are fast enough for most
things

16. ...I think now there's a better
way

17. Let's
**really**
embrace the
medium

18. Let's implement
the GUI of our
webapps on the
browser

19. Let's implement
the GUI of our
webapps on the
browser
all of it

21. And we'll use the server
for the business logic.

22. And we'll use the server
for the business logic.
For a services
layer

23. And we'll use the server
for the business logic.
For a services
layer
(and services are also cool now)

24. But why should we?

25. Because apps get
easier to develop
when we don't have to fight
against the platform

26. Because we can
make better,
faster, more
responsive apps
that take advantage of all of
the mediums's possibilities

27. Because at the end
you'll get an API
thrown in for free

28. Are you convinced?

29. So,
Why REST?

30. Because it’s not
SOAP
:)

31. First,
a short primer on
REST

32. REST: REpresentational State
Transfer
Cool acronym, but terrible
name

33. Central to REST is
the concept of
Resources

34. Resources are referenced
by a global identifier
e.g., an URI

35. Resources can have
different representations
text/html, application/json, application/vnd.ms-
excel

36. Communication is done
via a standard interface
HTTP, with all it's methods (GET, PUT, POST,
DELETE, etc.)

37. You do things in REST by
transferring
representations of the
state of a resource

38. the
Richardson
Maturity
Model

39. Level 0
One URI, one HTTP method

40. Level 1
Many URIs, one HTTP
method

41. Level 2
Many URIs,
each supporting many HTTP
methods

42. Level 3
HATEOAS (Hypertext As The Engine Of Application State)
using links for state
transitions

43. And we come to
the advantages of
REST

44. Its Simple

45. Its Proven

46. It scales **really**
well

47. There’s great
language support
for it
in all the languages that you’ll want
to use

48. But, most importantly,
that's what the
browsers speak

49. And,
on the
Browser
side?

50. We’re building a
GUI
Let’s turn to GUI patterns

51. MVC
An old favorite,
lots of documentation,
lots of experience

52. MVP
Very similar to MVC,
with some differences which
I think make it better.

53. M for Model

54. M for Model
communicates with
the server

55. M for Model
encapsulates the
logic of the
resources being
manipulated.

56. M for Model
gives access to the
data

57. M for Model
raises events when
something
interesting
happens
most often when the data changes in some way

58. V for View

59. V for View
notifies the
Presenter of the
user's actions

60. V for View
abstracts the DOM
manipulation
details

61. P for Presenter

62. P for Presenter
tells the model to
read data from the
server

63. P for Presenter
receives events
from the model

64. P for Presenter
reads data from
the model

65. P for Presenter
instructs the view
to present the data

66. P for Presenter
receives
notifications from
the view of the
user's actions

67. P for Presenter
updates the model

68. P for Presenter
instructs the model
to send the data to
the server

69. There's
**absolutely no
communication**
between the Model
and the View

70. A Presenter may
subscribe to events
from multiple
Models

71. A Presenter may
command multiple
Views

72. Presenters can
communicate with
each other, but
one-way
communication is
preferred

74. Advantages?

75. Strict separation of
the DOM
manipulation code

76. Easier Testing

77. one place to look
to understand the
GUI logic

78. one place to look
for data
manipulation

79. DEMO
TIME

80. Lets
wrap up

81. Thank you!
@jnelas