How we built our app in 2 weeks using Ionic Framework
In this technical retrospective (2014), @rayv shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 160 points
TOTAL DISCUSSIONS 100 comments
We just built a mostly done prototype of one of our products with Ionic in 4 weeks at my company, rewriting existing components to take advantage of Ionic. We ran into a bunch of Ionic bugs (on beta 13), and took a dive into integrating the beta 14 candidate with Angular 1.3 into the prototype (and came upon what looks like ng-animate bugs in 1.3) last night. We are also using CCA.
Ionic has pretty much been a joy to use, and fit exactly our requirements (we do hybrid web/mobile apps on my team, mobile being Android only since we do native iOS development). The article is pretty much on the mark, and you need to be careful when it comes to performance on mobile. Optimizing stuff like using the track by syntax with ng-repeat is vital. Taking advantage of Angular's superior testability and structure conducive for rapid app development (and having 3 Angular contributors on the team doesn't hurt) allowed us to build an impressive app very quickly, as well as avoid some of the nasty Ionic bugs we came upon (mostly related to their $viewHistory service and broken back button).
I haven't gotten to play around with the beta 14 candidate yet, but I was unhappy with how opinionated Ionic was when it came to the history and how it's expected that everything would inherit from a state with tabs.
I will say this though - if it wasn't for the decision to use Ionic, we would have been in a lot of pain trying to meet our deadlines trying to write a lot of this functionality from scratch, and we would not have had stuff like the native feel with the tapping & scrolling behavior that Ionic provides. Overall the Ionic team did a great job with the product, and I'm pretty happy with it.
Mobile app is most most certainly going to be made using html and javascript in the time to come. Ionic and angular is great for building mobile apps with standard mobile UI elements like headers with back buttons and chevrons, pages that slides in from the side, modals and tab bars at the bottom of the screen. Everything is meticulously created in html, css and javascript. Scrolling is good enough for most usecases, but if your pages contains long list views with graphic elements the page starts to lag.
However if you use famo.us' list view scrolling is nearly as fast and smooth as native code on iPhone 4. On newer phones to difference between hybrid apps and native is unnoticeable. At the moment famo.us only has low level components, like boxes with html content. Standard back buttons, chevrons, tabs, action sheets and icons has to be imported from elsewhere. Famo.us only does fast bouncy animations, touch events and 3d effects. Besides famo.us is working on their phonegap/cordova alternative wrapper.
A combination of Ionics ease of use and famo.us' impressive speed would have been great. There's lot of promising little open source projects on github that either extends famo.us or integrates it with javascript MVC libraries.
I believe Brendan Eich was right when he said "Always bet on JS!". I bet mobile app development is going to be dominated by JavaScript and HTML.
If there's any sort of app that works with this sort of thing, then yours is probably at the top of the list. The interface is super-simple, people are unlikely to use it often, and so on.
In this case, the cost of developing independent apps for Android and iOS (as well as other platforms, potentially) would probably be too high.
The experience wouldn't be suitable for anything used more intensely though, IMO. Scrolling on iOS is just "not right", in the sense that behaviour is different to native apps. Hover behaviour is different too, and some of the UI elements are also not quite correct (back button). Small things like that add up in a bigger app and cause a frustrating experience.
But it's definitely a good turn-around time, and FWIW I think you've made the right decision to take this approach.
Also recommend to everyone who needs Cordova to look at AppGyver Steroids[1]. It's truly hybrid framework, though, still under active development. For example, Steroids has layers system, which basically consist of WebViews, but all transitions is native and Steroids gives you native controls such as NavigationBar and TabBar. I'm making an iOS app right now and I've got shared .styl, .jade templates and a bit of .js logic between web node.js and mobile app. From Ionic I use IonicIcons, and I love it.
[1] http://www.appgyver.com/ ↗ [2] http://ionicons.com/ ↗
Just installed it and I think this is the perfect sweet spot for this kind of wrapped webapp. The app is simple (but useful) and still leverages native things like the select combo and date time pickers. The transitions between the two screens are smooth and the list scrolling feels great.
I suppose my only query is... why bother with ionic? This is such a simple application that it almost feels overkill, you could have used the cordova commandline tools along with libraries like iscroll and fastclick and you'd have had everything you've got here with less overhead...