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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rich Web Applications with Aspenware

634

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 …

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
634
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

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  

×