From Bucks County Tech Meetup 2015-05-26

1. Creating a Responsive Website From
Scratch

2. Creating a Responsive
Website From Scratch
• Corky Brown – Application Architect; ~9 years at
MeetMe.com; back- and front-end development
• Javier Barreto – Web developer; 8 years; mostly
back-end, more recently front-end
• Bill Sykes – Web developer; new to MeetMe, 10
years experience back- and front-end

3. Creating a Responsive
Website From Scratch

11. Something’s missing…
• User has a smartphone
• First time visiting meetme.com
• Does not want the native app
• Cannot install the native app

13. Why?
• Users get…
• Modern, native-ish experience
• Feature parity with native apps
• MeetMe gets…
• Better engagement
• Better monetization
• Feature parity with native apps
• Single server-side API
• Work off-loaded to the clients

14. Everybody wins!

15. What’s the catch?

18. “Responsive website”
Phoenix

20. “From scratch”

22. 6 months later…

24. Why make it from scratch?
• Current website is years upon years of legacy
code.
• Easier to work with new libraries and tools
• Great chance to reimagine our entire development
process
• Development will be faster
Phoenix

25. Goals
• One website to manage – mobile, desktop, in between
• Many servers -> one (redundant) server + CDN
• Use Mobile API
• Leverage open source community
• Support smartphone browser+OS+device
combinations that use MeetMe
• Organize into releases Phoenix

26. Organize Into Releases
• Better tracking of bugs & features historically
• Keeps team focused
• Brings us in-line with the native mobile apps
• Use semantic versioning (semver.org)
Phoenix

27. Focuses

28. Focuses
• Support as many users as quickly as possible
• Fast development
• Well-scoped code
• Documentation
• Standards
• Testing
• Automated builds

29. Support as many users as
quickly as possible
• Focus on top browser & OS (Chrome on Android)
first, ignore others.
• Gamble: one browser will give us a great
foundation for the next and it should get easier as
we go along (more on this later).

30. Fast Development
• Get end-to-end as soon as possible, optimize
going forward
• Dev -> Staging -> Production
• As we optimize this workflow and add tests, we can
push faster

31. Well-Scoped Code
• Let good code thrive
• Minimize scope of compromises
• Feature and bug detection, not browser detection

32. Documentation
• jsdoc
• auto-generate
• require in code review

33. Standards
• Style
• Best practices
• Pick an existing standard
• jslint/jshint
• Google’s docs for style and annotation

34. Testing
• Unit tests (jasmine + karma)
• Behavior tests (cucumber + ruby or js)
• Builds auto-generated for QA at URL (with QR
code from http://goqr.me/)

35. Automated Builds
• Continuous Integration
• Jenkins CI (jenkins-ci.org)
• Grunt.js (gruntjs.com)

36. Non-Focuses

37. Non-Focuses
• Clients that we don’t support
• Performance (to a degree)
• SEO

38. Performance
• (to a degree)
• Trust that QA will report performance issues (and
they did)
• Devices we are targeting can handle what we’re
doing (nothing too intensive)
• Browsers and OSes dedicate a lot to JS and CSS
processing

39. SEO
• Common problem for “single page dynamic
websites”.
• Our current mobile site is crawled & “Mobile-
friendly”, according to Google. We redirect
supported clients from there to touch.meetme.com.
• We can skip and revisit later

40. Principles & Practices

41. Principles & Practices
• Well-scoped code
• Leverage third-party and open source libraries and
tools (Bill)
• Tools for responsive and mobile web development
(Javier)

42. Well-Scoped Code
requirejs or equivalent (browserify)
// js/lib/models/member/MemberPrivacyModel.js
define([‘lodash', 'Backbone'], function(_, Backbone) {
'use strict’;
return function() {
//
};
});

43. Well-Scoped Code
Say What You Do
(Not Why You Do It)
(And Not How You Do It)
// js/lib/helpers/RequestHelper.js
var errorsToHandle = {
'MemberException' : {
'code_1' : displayLoginModal
},
//
};

44. Well-Scoped Code
Say What You Do
(Not Why You Do It)
(And Not How You Do It)
// js/lib/helpers/RequestHelper.js
var errorsToHandle = {
'MemberException' : {
'code_1' : requestUserAuthentication
},
//
};

45. Well-Scoped Code
Do it the “right” way first (HTML5 and community accepted)
Keep “fixes” in one function or variable and gracefully fall back
http://caniuse.com/#feat=flexbox

46. Well-Scoped Code
Do it the “right” way first (HTML5 and community accepted)
Keep “fixes” in one function or variable and gracefully fall back
// less/mixins/flex.less
.flex-display {
display: -webkit-flex;
display: -moz-flex;
display: -ms-flex;
display: -o-flex;
display: flex;
}

47. Well-Scoped Code
Do it the “right” way first (HTML5 and community accepted)
Keep “fixes” in one function or variable and gracefully fall back
Detect bugs and features, not browsers and devices (modernizr.com)
When the browser or device manufacturer fixes the bug, your code
should still work

48. Third-Party, Open Source
• Bootstrap (getbootstrap.com) – responsive UI
• Backbone (backbonejs.org) – models, collections, views, router
• Lodash (lodash.com) – utility library
• Grunt (gruntjs.com) – task runner
• LESS (lesscss.org) – dynamic CSS
• Handlebars (handlebarsjs.com) – templating
• requirejs (requirejs.org) – module & scope management

49. Leverage third-party and
open source libraries and
tools (Bill)

50. Tools for responsive and
mobile web development
(Javier)

51. Lessons

52. Lessons
• Browsers: quirkier than we imagined
• Some bugs cannot be detected (or not easily).
Treat as though you did detect it!
• Can’t reliably detect device

53. The Future
• Revisit
• SEO
• Render on server first (Rendr, et al.)
• File size & number of requests
• Performance
• Improvements
• React

54. Questions?