Your SlideShare is downloading. ×
1	
  
•  Who	
  here	
  considers	
  themselves	
  solely	
  a	
  backend	
  developer?	
  The	
  thought	
  of	
  
wri<ng	
  HT...
I	
  would	
  like	
  to	
  thank	
  Chris	
  Wallace.	
  Chris	
  thank	
  you	
  for	
  allow	
  us	
  to	
  be	
  here	...
4	
  
•  Let’s	
  start	
  off	
  tonight’s	
  discussion	
  with	
  a	
  thought	
  provoking	
  quote	
  by	
  Ryan	
  Singer,	...
•  The	
  term	
  Rich	
  Web	
  Applica<on	
  and	
  Rich	
  Internet	
  Applica<on	
  are	
  conflated	
  and	
  
confuse...
•  RWAs	
  are	
  synonymous	
  with	
  the	
  term	
  “Web	
  2.0”	
  (coined	
  by	
  Darcy	
  DiNucci	
  and	
  
later	...
•  The	
  types	
  of	
  applica<ons	
  that	
  we	
  are	
  building	
  today	
  are	
  very	
  much	
  like	
  the	
  ea...
•  The	
  web	
  is	
  where	
  our	
  interests	
  are	
  
•  I	
  downloaded	
  the	
  graph	
  because	
  I	
  thought	...
10	
  
•  What	
  we	
  recognize	
  as	
  the	
  Internet	
  and	
  the	
  World	
  Wide	
  Web	
  really	
  began	
  in	
  1991...
•  The	
  2000’s	
  saw	
  the	
  birth	
  of	
  the	
  RWA	
  
•  Applica<ons	
  like	
  Gmail,	
  Google	
  Maps,	
  and...
13	
  
•  My	
  RWA	
  and	
  my	
  web	
  service	
  don’t	
  have	
  to	
  know	
  anything	
  about	
  one	
  another.	
  	
  ...
15	
  
This	
  graph	
  trends	
  ac<vity	
  on	
  various	
  Open	
  Source	
  JavaScript	
  libraries	
  and	
  frameworks	
  
...
17	
  
Modern	
  Rich	
  Web	
  Applica<ons	
  now	
  assume	
  similar	
  architectural	
  paOerns	
  as	
  the	
  
server-­‐sid...
19	
  
The	
  idea	
  of	
  a	
  rich,	
  browser	
  based	
  experience	
  was	
  not	
  only	
  borne	
  out	
  of	
  the	
  ne...
• 
• 
• 
• 
• 

The	
  user’s	
  needs	
  are	
  more	
  qualita<ve.	
  
Think	
  of	
  this	
  slide	
  as	
  Abraham	
  ...
22	
  
•  Op<mizing	
  your	
  web	
  applica<on	
  does	
  become	
  more	
  challenging,	
  but	
  its	
  not	
  as	
  bad	
  
...
24	
  
25	
  
26	
  
27	
  
28	
  
29	
  
30	
  
31	
  
Upcoming SlideShare
Loading in...5
×

Rich Web Applications with Aspenware

669

Published on

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.

Published in: Technology, Education, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
669
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Rich Web Applications with Aspenware"

  1. 1. 1  
  2. 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. 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. 4  
  5. 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. 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. 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. 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. 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. 10  
  11. 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. 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. 13  
  14. 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. 15  
  16. 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. 17  
  18. 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. 19  
  20. 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. 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. 22  
  23. 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. 24  
  25. 25. 25  
  26. 26. 26  
  27. 27. 27  
  28. 28. 28  
  29. 29. 29  
  30. 30. 30  
  31. 31. 31  

×