Five stages of grief: Evolving a multi-page web app to a single page application
9 likes19,314 views
This document discusses evolving a multi-page web application to a single page application. It outlines the five stages of grief experienced during this process: denial, anger, bargaining, depression, and acceptance. Initially, the team was in denial that a SPA was needed. They then experienced anger when issues arose. Through bargaining, they realized a new architecture was required. Depression set in due to the challenges of converting the existing app. Finally, the team accepted piece-wise refactoring as the solution to bridge the gap.
Ad
More Related Content
Viewers also liked (20)
Similar to Five stages of grief: Evolving a multi-page web app to a single page application (20)
Ad
Five stages of grief: Evolving a multi-page web app to a single page application
- 1. Five Stages of Grief: Evolving a Multi-Page Web App to a Single Page Application Dallas, TX 11th April 2013 The Business of IT® www.parivedasolutions.com
- 2. Who are we? And why should you listen to us? Charles Knight ► Charles Knight • Graduate of the University of Texas at Austin (MIS) • 6+ years of Agile Software Development in MSFT technologies • Senior Manager at Pariveda Solutions • [email protected] om Kevin Burnett ► Kevin Burnett • Graduate of the University of Texas at Austin (Aerospace) • Front-end guru: HTML, CSS, JavaScript, PHP, Rails, C# • Consultant at Pariveda Solutions • [email protected] m 2
- 3. Table of Contents ► Background & A Real World Business Problem ► Denial – “We’re fine, we don’t need a Single Page Application (SPA)” ► Anger – “Dang it! I knew we should’ve built a SPA…” ► Bargaining – “OK fine, we’ll do what we can to convert this thing to a SPA” ► Depression – “Shoot, are we going to have to stick with the old app?” ► Acceptance – “It’s going to be okay, we have a way to bridge the gap” ► Closing Thoughts ► Questions 3
- 4. Background & A Real World Business Problem Acceptance Denial Bargaining Anger Depression Background 4
- 5. Background What are we talking about today? Popular SPA Example: Gmail ► Single Page Applications (SPA) • Follows the App + API architecture model ► Multi Page Applications (MPA) • Follows the traditional n-tier / client-server architecture model John Papa on Pluralsight ► What are we NOT talking about? • Building a SPA from scratch using the latest and greatest • Highly recommend following/listening to John Papa Kubler-Ross Model ► We’ll be telling our real-life story of evolving a MPA to a SPA Acceptance Denial Bargaining Anger Background Depression 5
- 6. Background What is a Single Page Application? ► Single HTML page is loaded when the user initially loads the app ► Heavy emphasis on JavaScript ► Consumes data asynchronously from a RESTful API ► URL doesn’t change except for hash (#) ► No page reloads ► Universally accessible through a web browser 6
- 7. Background Why should you care? Consumer Apps ► Customer expectations of applications have changed ► The “bar” has been raised for enterprise apps Microsoft Technologies ► Microsoft is getting behind this idea Polyglot graph % of Programmers ► Polyglot programming is a requirement these days (JavaScript is everywhere!) 7 Time Coding
- 8. Background Here’s a real world business problem we were faced with ► A Global Fortune 500 / S&P 500 company ► Company realized they needed to leapfrog their competition ► Had gobs of data and needed cool visualizations (WOW factor) ► Agreed to focus on modern browsers (plus IE8) ► Aggressive development timeframe to deliver in time for client budget season (9 weeks) 8
- 9. Denial – “We’re fine, we don’t need a Single Page Application (SPA)” Acceptance Denial Bargaining Anger Depression Background 9
- 10. Denial Our technology solution to this problem looks very familiar and safe at first glance Typical Application Architecture ► Modernizr Client ► jQuery ► Foundation 2 ► HTML/CSS ► JavaScript ► Razor Pages ► ASP.NET MVC3 Server ► Entity Framework ► SQL Server 2008 DEMO: Let’s take a look at the solution 10
- 11. Denial Our initial instincts had us researching SPA frameworks, but we refused to acknowledge the fact that we were trying to build a SPA within a MPA architecture ► Briefly looked at Knockout.js ► Started with the admin section which didn’t have the “Wow” factor requirement ► Needed more time to digest requirements and design a solution ► Ended up with some SPA like capability constrained within a MPA architecture 11
- 12. Denial TAKEAWAY: You must understand when it makes more sense to build a SPA over a MPA (and take the time to make the decision!) ► Heavy Static Content Focus ► SEO requirement ► Lack of JavaScript experience ► Need to support older browsers ► API availability and desirability ► Real-time performance requirement ► High UX requirement 12
- 13. Anger – “Dang it! I knew we should’ve built a SPA…” Acceptance Denial Bargaining Anger Depression Background 13
- 14. Anger Eventually, we began experiencing pain points which ultimately convinced us that our initial architecture was preventing us from realizing maximum value from a SPA ► Handling browser history / navigation / and bookmarking ► Maintaining State (dropdown selections, etc.) ► Performance degradation as # of view increased ► Decreased maintainability as additional views were added Kevin Angry! DEMO: Let’s see first hand the issues that caused our pain 14
- 15. Anger TAKEAWAY: You must simulate a lot of built-in browser features when building a SPA ► History navigation with browser back and forward buttons ► Canceling or stopping a load with the ESC or stop button ► Visual indicator that a page is loading ► Bookmarkability of pages ► Ability to open a page link in another tab / window ► Reloading the page should bring you back to where you last we ► Timeout detection in the event something goes wrong 15
- 16. Bargaining – “OK fine, we’ll do what we can to convert this thing to a SPA” Acceptance Denial Bargaining Anger Depression Background 16
- 17. Bargaining We finally realized that we needed to shift how we thought about the application architecture if we were to really build a SPA Typical Application Architecture SPA Architecture ► Modernizr ► Modernizr ► jQuery ► jQuery ► Foundation 2 Client ► Foundation 2 ► HTML/CSS HTML ► HTML/CSS ► JavaScript ► A lot of JavaScrip ► Razor Pages JSON HTML JSON ► ASP.NET MVC3 ► JSON ► ASP.NET Web API Server ► Entity Framework ► Entity Framework ► SQL Server 2008 ► SQL Server 2008 DEMO: Let’s take a look at a Single Page Application solution 17
- 18. Bargaining TAKEAWAY: You must build a well thought out client-side application architecture and should leverage mature open-source JavaScript libraries where you can Client-side Architecture Breakdown ► Dependency Resolution / Module Loader SPA Architecture ► DOM / AJAX ► Data Binding / Client MVVM Framework ► Navigation / History ► Helpers ► Data Push / Pull, Storage, Messaging 18
- 19. Depression – “Shoot, are we going to have to stick with the old app?” Acceptance Denial Bargaining Anger Depression Background 19
- 20. Depression Trying to convert a MPA to a SPA while continuing to build new functionality is like trying to change the tires on a moving car ► Wasn’t feasible to do a rewrite from scratch ► Limited time and resources prevented us from easily implementing the needed new client-side architecture ► Required everyone on the team to learn new patterns and practices before they could be 100% effective DEMO: Let’s take a look at the JavaScript and focus in on some patterns and practices 20
- 21. Depression TAKEAWAY: You must follow proper design patterns and practices to avoid building a JavaScript application that is unwieldy and difficult to maintain and enhance ► Employ separation of concerns ► Use a MV* framework where possible ► Scope your objects appropriately ► Write modular decoupled code ► Test your code thoroughly 21
- 22. Acceptance – “It’s going to be okay, we have a way to bridge the gap” Acceptance Denial Bargaining Anger Depression Background 22
- 23. Acceptance We eventually accepted the fact that evolving a MPA to a SPA would take time and effort Where we wanted to go Where we were Piece-wise refactoring DEMO: Let’s write some code! 23
- 24. Closing Thoughts 24
- 25. Closing FINAL TAKEAWAY: You can create rich web applications with SPAs but it requires planning, a specific application architecture, and a different developer skillset ► Do you have or want a RESTful API that returns JSON? ► How much (recent) JavaScript experience does you and your team have? ► Are you targeting specific browsers or are required to support a certain browser? ► Which framework will you use? ► Expect rapid changes in client-side technologies and plan accordingly ► Plan and expect to refactor code frequently ► Invest in learning client-side technologies and tools ► Don’t be afraid to test client-side code! 25
- 26. Closing What tools and frameworks are available to those wanting to build a SPA? Opinionated Flexible Library Framework Where should you go to evaluate these frameworks? http://todomvc.com/ 26
- 27. Closing Learning Resources ► http://html5boilerplate.com/ ► http://modernizr.com/ ► http://caniuse.com/ ► http://jsfiddle.net/ ► http://todomvc.com/ ► http://www.johnpapa.net/spa/ ► http://pluralsight.com/training/Courses 27
- 28. Questions? 28
Editor's Notes
- #7: Single Page Applications are a class of web application that follow the App + API architecture model.Heavily relies upon JavaScript, a server-side RESTful API, and a single HTML page. Once the single page is loaded upon the initial request, the application dynamically updates parts of the page based on user interactions through AJAX calls to the RESTful API. -Views the modern browser as a legitimate application platform-Embraces HTML5, JavaScript, and CSS as enterprise class programming languages-Focused on intuitive design and a richer and more responsive user experience-Consumes JSON data from RESTful APIs
- #8: Caused by heavy investment in consumer-facing apps like Facebook, Twitter, and GmailDriven by advances in browsers and client-side technologiesSimple yet feature rich capabilities accessible on an ever increasing range of devices investing heavily in web api (anyone attend dallas day of dot net and hear scott hunter?)opening VS and ASP.NET to the community, welcoming community templates for SPAsJS is very popular and such a prolific programming language (Win8 apps, browser as a legit app platform)
- #9: The main challenge was to deliver an application that summarized and simplified the large amounts of data made available by the client and provide a “Wow” factor for their customers, while adhering to an aggressive development timeframe to coincide with their client's customer’s budget cycles
- #11: typical server-side mvc applicationasp.net mvc3, ef, sqlfoundation3, modernizr, jquery
- #12: We briefly looked at knockout.js but didn’t have time to move up the learning curve enough to understand the implications of NOT using a JS framework.
- #16: We compete with a lot of useful browser features that we need to simulate: