queries (with one codebase for all devices) typically works best for web “sites” (not apps). Apps work best when tailored to one particular interaction paradigm. For instance, mobile Gmail is a different experience than on the desktop. As a general rule of thumb, if your content can be read via RSS (such as Google Reader) and still make sense, it might be worth considering a responsive approach.
the IE10 engine (it is pretty good) — WebKit is the dominant rendering engine across most mobile devices — iOS, Android, Blackberry, webOS — Blackberry has one of the best WebKit-based browsers available
(UI conventions) — Performance (“closer to the metal”) — Access to device hardware (GPS, etc) — App store/marketplace distribution — Benefit from latest OS enhancements
in-house, and I don’t think people noticed a big difference. Nobody said, “Oh that’s native,” or “Oh, that’s web.” As long as we can make the experience fast enough, nobody can tell the difference. It still feels right. — Kiran Prasad http://venturebeat.com/2012/05/02/linkedin-ipad-app-engineering
— Access to device hardware (GPS, etc) — App store/marketplace distribution — Skills you already have (HTML, CSS, JS) — Potential code reuse in web site/app
— 3rd party SDK’s might lag behind OS — Want to use feature X? Wait for an implementation in abstraction layer. — An abstraction layer can have bugs of its own. Have to determine if a bug is in your code, the abstraction layer, or OS.
came to HTML5 — Sending down HTML, CSS, JS to the app, rather than building the app with that embedded, and consuming lightweight JSON sent from the server. “A craftsman doesn’t blame his tools”
iOS, crapshoot on Android — Build for iOS, Android, and Blackberry — Some code reuse across platforms — Entirely JavaScript based — Uses CommonJS’s AMD approach — Except for WebView (HTML/CSS too)
languages — Objective-C, C#, or Java — whilst using an IDE such as Visual Studio, Xcode, or Eclipse. With “the web,” you have familiar browser-based desktop tools in Chrome, Firebug, or Opera Dragonfly.
Native app gives access to OS API’s — All the UI is built via HTML/CSS — JavaScript handles everything else — The app wrapper compiles via… Xcode, Eclipse, Visual Studio, or “the cloud” → build.phonegap.com How PhoneGap works
already know” — Debugging via desktop browser — Access to device API’s (GPS, etc) — Strives to implement W3C specs — Camera API, etc. — Supports Windows Phone, too
including IE9. src: url('../fonts/OpenSans-Regular-webfont.woff') format('woff'), // For older IE, and Android default browser. url('../fonts/OpenSans-Regular-webfont.ttf') format('truetype'); } @font-face { font-family: 'Open Sans'; font-weight: bold; // For all good browsers, including IE9. src: url('../fonts/OpenSans-Bold-webfont.woff') format('woff'), // For older IE, and Android default browser. url('../fonts/OpenSans-Bold-webfont.ttf') format('truetype'); } All modern browsers support *.woff or *.ttf
the magic of Handlebars happens Yes, this looks underwhelming. That’s the point. It’s code you don’t have to write yourself! :) http://host.sonspring.com/handlebbbars/assets/js/application.js