Download to read offline
Uploaded byAspenware
Rich Web Applications with Aspenware
The document discusses the evolution of web development, contrasting traditional Rich Internet Applications (RIAs) with modern Rich Web Applications (RWAs) which utilize standardized technologies like HTML, CSS, and JavaScript. It emphasizes the shift towards simpler, modular architectures that allow for better scalability and user experience, while also highlighting the importance of engineering practices in the development process. The author notes that as the web evolves, applications are increasingly designed to meet higher-order user needs while minimizing complexity.
More Related Content
Similar to Rich Web Applications with Aspenware
Rich Web Applications with Aspenware
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.