Rich Web Applications with Aspenware
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Rich Web Applications with Aspenware

  • 808 views
Uploaded 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......

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
808
On Slideshare
744
From Embeds
64
Number of Embeds
3

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 64

http://www.aspenware.com 34
http://authoring.aspenware.com 29
http://aspenware.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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