Build Single-Page Apps

Transcript

1. Please install NodeJS: http://nodejs.org/
2. BUILD SINGLE-PAGE APPS BY TESSA HARMON OF Slide background credit: Escheresque from Subtle Patterns: http://subtlepatterns.com/ escheresque/
3. Tessa Harmon tessa@skookum.com @TessaHarmon - From Charlotte - 6 years of software dev experience, past year focused on SPAs - Co-organizer of CLTFED for over a year - Local speaker at UX/dev groups
4. This is a picture of my puppy Nico, just because.
5. WHAT i A SINGLE-PAGE APP? - Broad definition: All HTML, CSS, and JS is loaded onto one page (either all at once or dynamically). New content is most commonly loaded via AJAX without a page refresh. Could also be websockets, flash, silverlight, etc Examples: GitHub, GMail, Rdio, Azure portal
6. CHARACTERISTICS OF GOOD SPAS •Based on HTML, CSS, and JS •Doesn’t break the browser. •Fast & Responsive: should feel like a native application •Accessible: Makes good use of WAI-ARIA - Avoid proprietary tech. - SPAs should not stray too far from the way traditional sites are rendered, unless there is good reason to. Features of the browser, such as scrolling, the back button, using “Enter” to submit forms, etc., should behave as expected. Be intentional about breaking these paradigms, and test the hell out of them. •There’s no point in building a SPA if it’s not faster than a server-side app. •You CAN make JS apps accessible, and it’s probably easier than you think. http://www.w3.org/WAI/ intro/aria
7. IDEAL USE CASES •Data-intensive web apps •Mobile (pair with cache manifest and local storage = offline use) •Highly interactive web apps
8. LESS THAN IDEAL USE CASES •Content sites, product sites, or blogs because of search indexing • Generally, SPAs are not public and have marketing pages that can be indexed by search engines •If high interactivity is not needed
9. FRAMEWORKS & LIBRARIES
10. ater onn ate. Do you think Oscar Wilde would have cared what other people thought about his JavaScript habits? NO! Image source: Wikimedia Commons, c. 1882. http://en.wikipedia.org/wiki/File:A_Wilde_time_3.jpg
11. COMMON FEATURES •Data bindings •MVC-ish •Routing •Encourages modularization - Web applications should be based on data models, not just AJAX
12. COMPARISON Views URL Routing Data Storage AngularJS Built-in DOM-based templates (optional) Built-in (optional) Built-in (optional) Backbone BYO Built-in (optional) Built-in (overridable) Ember Built-in string-based templates (optional) Built-in (mandatory) Built-in (overridable) Knockout Built-in DOM-based templates (optional) BYO BYO Thanks to Steve Sanderson’s awesome blog post about this: http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne- of-js-2012/ Explain about frameworks vs libraries (KO & Backbone are more like libraries; Angular and Ember are frameworks) I prefer AngularJS because it gets out of your way.
13. I ♥ AngularJS Very light framework Good defaults Encourages good design patterns Easy to test Ideal for CRUD apps, but not games or lower level things.
14. CONTROVERSY & CRITICISM
15. “It’s no longer good enough to build web apps around full page loads and then ‘progressively enhance’ them to behave more dynamically.” —Throne of JS Conference Site, 2012 http://throneofjs.com/
16. “If you’re not using [a client- side framework], you’re either not building an application, or you’re just missing out.” —Steve Sanderson, Knockout Core Member http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne- of-js-2012/
17. “ he report of my deat have been greatly exaggerate .” —Progressive Enhancement* (*actually, Mark Twain) Progressive enhancement is still extremely relevant, especially with public-facing apps. Especially for mobile users, users in 3rd world countries, slow Internet connections, etc. Not all apps are worth doing in JS Stay open-minded!
18. LET’S BUILD! We’ll be going from Angular Seed to Deployed App.
19. Step 0 github.com/TessaHarmon/blendsongs $ git clone https://github.com/ TessaHarmon/blendsongs.git $ git checkout -f step-0 $ node scripts/web-server.js Navigate your browser to: http://localhost:8000/app/index.html
20. Step 1 $ git checkout -f step-1 Loading data into a view Declarative DOM templates Testing - Discuss different sources for data - Show off MVC, routing, template syntax - Where the data is fetched in the controller, show how it would look with DOM manipulation, and explain why it’s fragile. If you want to do something with jQuery, there’s probably a better way.
21. Step 2 $ git checkout -f step-2 Show a progress bar while data is loading. Allow a user to filter the table. Add sorting to the table. Promises (success & then) Success and then Discuss data binding Show the updated test
22. Step 3 $ git checkout -f step-3 Allow the user to sort the data by column header Dynamic class names in Angular
23. Step 4 $ git checkout -f step-4 Fetch songs through a service instead of the controller Dependency Injection
24. Step 5 $ git checkout -f step-5 Load the songs from Firebase Allow a user to add their own songs Demonstrate adding a song and it showing up instantaneously Show timestamp field New controller BlendSongs DB service (reduce repetition) Angular Form validation
25. Step 6 $ git checkout -f step-6 Put the app into a build system Deploy it to GitHub Show how controllers are broken into multiple files Explain benefits of using a build system, show off brunch (config, file layout, etc) Discuss modularization strategies
26. Technical Review Credits David Becher Patrick Faulkner Dustan Kasten Eric La Force Keith La Force
27. Tessa Harmon tessa@skookum.com @TessaHarmon