Downloaded 15 times
Uploaded byArthur Fung
Single page application
This document discusses single page applications (SPAs) and provides an overview of what SPAs are and their advantages compared to traditional websites. It defines SPAs as web applications that fit on a single web page and provide a more desktop-like user experience through features like fluid page transitions without reloads. The document outlines how SPAs move more of the application logic to the client, fetch data on demand, and support features like back/forward buttons and offline use. Examples of SPAs include Gmail and merchant locators.
More Related Content
Similar to Single page application
Single page application
- 1. SPA Brown Bag Sessionby Arthur Fung
- 2. We work hard!We deserve it! Oh yeah! Date: 3/31 - 4/4 Place: Napa Valley Duration: 1 week! Fee: Priceless TACPOINT IS AWESOME
- 3. WHAT IS SPA?? NICETRY PEOPLE!
- 4. Single Page Application Asingle-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.
- 5. Desktop ● Fast Response ●Capable of rendering portion of the UI ● More interactive with the user ● Cross Platform ● Universally accessible ● Instantly updated and distributed Traditional Website ● Platform Specific. ● Only accessible on installed machine ● Needs users to manually update the application ● Slow. Page Flash. ● Universally accessible ● Instantly updated and distributed
- 6. In fact, SPAcan provide the best of BOTH worlds.
- 7.
- 8.
- 9. What is aSingle Page Application? ● Fluid transitions between page, richer interaction between UI componenets. No page refresh ● Application logic in the client ● Fetch Data on demand ● Dynamic Data Loading, usually with Rest API ● Back/Forward Button works as expected ● Support bookmark ● Ability to go offline
- 10. Advantages of SPA ●Responsive, Native Appplication Feel. No page blink. ● Faster UI, More Interactive ● More work on client side, offloading the server responsibility ● REST endpoints are more general purpose ● Perfect for supporting multiple platofmrs, since UI is just another client ● Share benefits from both desktop and web app
- 11.
- 12.
- 13. Model View Controller ●The Model, which provides the data and business rules of the application. ● The View, which provides the sensory (usually visual, but also often audio) representation of the Model’s data. ● The Controller, which converts requests from the user into commands that ● update the Model and/or View of an application. ● Our SPA moves as much of the application to the browser as possible. ● The whole MVC moves to the client
- 14.
- 15. What is thegoal? ● Provide a radically faster and widely accessible getting started experience ● Be opinionated out of the box, but get out of the way quickly as requirements sstart to diverge from the defailts ● Provide a range of non-functional features that are common to large classes of projects ○ Embedded Servers ○ Security ○ Metrics ○ Externalized Configuration ● Absolutely no code generation and no requirement for XML ● Convension over configuration Introducing Spring Boot
- 16. Sample Code @Controller class Controller { @RequestMapping("/") @ResponseBody StringgetHome(){ return "Hello World"; } }
- 17. Instructions 1. Clone theproject from Git Hub 2. Open Eclipse and Import the project 3. Run https://github.com/spring-projects/spring-boot
- 18. Why MVC Frameworkon the Front-End? ● Avoid Re-inventing the wheel ● We ALL suck at Javascript ● Follow best practice. Avoid Spaghetti Code ● Modular Code and Scalibility ● DOM Manipulation + Templating + Routing Examples: Backbone.js, Ember.js, AngularJS, Spine, CanJS, React.js
- 19. Stop relying onJQuery my friend!
- 20. What is AngularJS? ●Client Side Browser App Framework ● Open Source ● MVC Framework on the browser git clone https://github.com/spring- guides/gs-consuming-rest-angularjs.git
- 21.
Editor's Notes
- #5 my definition: A single page application is a web app in which the majority of interactions are handled on the client without the need to reach a server, with a goal of providing a more fluid user experience
- #6 An SPA can render like a desktop application—The SPA redraws the parts of the interface that need to change only as needed. A traditional website, in compari- son, redraws the entire page on many user actions, resulting in a pause and a “flash” while the browser retrieves from the server and then redraws everything on the page. If the page is large, the server is busy, or the internet connection is slow, this flash can take several seconds or more, and the user has to guess when the page is ready to use again. This is a horrible experience when compared to the rapid rendering and immediate feedback of an SPA. ■ An SPA can respond like a desktop application—The SPA minimizes response time by moving working (transient) data and processing from the server to the browser as much as possible. The SPA has the data and business logic needed to make most decisions locally and therefore quickly. Only data validation, authen- tication, and permanent storage must remain on the server, for reasons we dis- cuss in chapters 6-8. A traditional website has most of the application logic on the server and the user must wait for a request/response/redraw cycle in response to much of their input. This can take several seconds, compared to the near immediate response of the SPA. ■ An SPA can notify users of its state like a desktop application—When an SPA does have to wait on a server, it can dynamically render a progress bar or busy indicator so the user isn’t befuddled by a delay. Compare this to a traditional website, where the user actually has to guess when the page is loaded and usable. ■ An SPA is nearly universally accessible like a website—Unlike most desktop applica- tions, users can access an SPA from any web connection and a decent browser. Today, the list includes smart phones, tablets, televisions, laptops, and desktop computers. ■ An SPA can be instantly updated and distributed like a website—The user doesn’t have to do anything to realize the benefits—when they reload the browser it works. The hassle of maintaining multiple concurrent versions of software is largely eliminated.7 The authors have worked on SPAs that have been built and 7 But not completely: what happens if the server-client data exchange format changes, yet many users have the prior version of software loaded in their browser? This can be accommodated with some forethought. Summary 21 updated multiple times in a single day. Desktop applications often require a download and administrative access to install a new version, and the interval between versions can be many months or years. ■ An SPA is cross-platform like a website—Unlike most desktop applications, a well- written SPA can work on any operating system that provides a modern HTML5 browser. Though usually this is considered a developer benefit, it’s extremely useful for many users who have a combination of devices—say Windows at work, a Mac at home, a Linux server, an Android phone, and an Amazon tablet.
- #7 the immediacy of a desktop application and the portability and accessibility of a website. The JavaScript SPA is available on over a billion devices that support a modern web browser and that don’t require any propri- etary plugins. With a little effort, it can support desktops, tablets, and smart phones run- ning many different operating systems. SPAs are easily updated and distributed, usually without requiring any action from the user. All of these benefits explain why you may want to make your next application an SPA.
- #10 Single Page Application is a web app in which the majority of interactions are handled on the client without the need to reach a server, with a goal of providing a more fluid user experience
- #19 Do you need to share a project with a designer, and have the flexibility for design work and development work to happen near-simultaneously? Do you require thorough unit testing for your solutions? Is it important for you to have reusable components, both within and across projects in your organization? Would you like more flexibility to change your user interface without having to refactor other logic in the code base?