rich web applications with aspenware

•  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

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

•  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

•  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

•  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

•  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

•  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

•  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

•  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

•  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

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

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

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

•  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

•  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

rich web applications with aspenware

Technology