A day rarely goes by without someone lamenting the “problems” of web technologies, often specifically on mobile. They’re either too slow, lack native look-and-feel, or just don’t have a smooth enough UX. Their death has long been prophesied in the annals of technology.
With Ionic, we’ve built our entire company around the idea that you can build fast, native feeling apps in a web environment, using the standard HTML, CSS, and Javascript we’ve been using on desktop for decades.
And it’s working. In just a few years Ionic developers have built top apps for the app stores, gaining millions of installs, five star ratings, and even features from Apple and Google. Clearly, for nearly one million Ionic apps and their users, the web platform is fast and good enough.
So, if the web platform is fast enough but developers are still building bad apps with it, what’s the issue?
The problem is the web stack is too low-level, especially for mobile apps.
The “Frankenapp”
When you set out to build a fast, high quality mobile app with web technologies, it’s not nearly as simple as just throwing in some “mobile-enabled” widgets, writing some jQuery, and calling it a day. Throwing together a responsive framework with a slider widget and a hamburger menu widget isn’t going to make your app feel like, well, an app. Instead, you get what often feels like a “Frankenapp.”
Mobile web developers have to build or find high quality components for everything from side menus, to tab UIs, to image sliders, to buttons and tap/gesture events. They have to build navigation concepts that are not found in a traditional browser environment (for example, the way history is nested in an iOS tabs-based app). They have to respond to different kinds of input events and have UIs that respond to complicated touch gestures.
These components don’t come for free with the browser, and they aren’t easy to build from scratch without experience designing and architecting UI SDKs (not to mention time and energy), a task better suited for a dense computer science class.
This is exactly why when you open [insert random news site] and tap the hamburger menu, they almost invariably feel clunky, slow, and flickery. None feel like a side menu in any native app we are used to.
It’s also why, when you open [insert random Ionic app], the side menus DO feel native. Yet we’re using the exact same technology and APIs.
Powerful Primitives
Browser technology has evolved to give web developers great primitives for rendering, animation, document traversal, and networking. But they’re just that: primitives. The only thing that’s easy about using them is using them incorrectly.
Every time we read and write from the DOM, or animate a property of an element, or respond to complicated touch and gesture events in our app, we are just begging to fall into a performance and user experience trap. It’s too much to ask of developers to use these powerful tools correctly all the time, especially when all they want to do is focus on what makes their app unique.
Very few developers should be using the browser primitives as-is. Instead, they should use frameworks. They should modify UI through an MV* framework like Angular, Ember, or React, which will properly batch and update the UI to avoid costly reflows and subsequent flickers. They should use mobile web frameworks like Kendo, Sencha, or Ionic to handle the actual mobile components (buttons, tabs, navigation, etc.) instead of writing their own, which are guaranteed to have performance and UX issues (for context: we’ve been agonizing over how to build the perfect mobile button for over two years!).
If you’re a Cordova/Phonegap developer, I implore you to use a mobile framework. Your homemade UI just does not look nor feel like a native app, period. This is the #1 reason Cordova has earned a reputation for being slow and non-native. It has nothing to do with what Cordova does, but everything with what it doesn’t do. Cordova is a simple web-to-native bridge with tools for building, testing, and packaging apps, not a mobile UI framework. It’s 50% (or less!) of the solution. Would you build Cordova from scratch for each app you build? Of course not! So, don’t do that with your UI components, either.
Compared to native
Web developers constantly hear how the web stack “sucks” in comparison to native. What we don’t realize is that native developers on any platform (desktop, mobile, xbox, desktop linux, etc.) are building apps at a higher level of abstraction than web developers. UI Kit on iOS comes with quality tabs, page sliders, pull to refresh, and content components. Java Swing has layout systems, desktop panes, draggable windows, and powerful form controls. Unity 3D gives game developers level systems, scene graphs, menu UI, and inverse kinematics tools.
These “native” developers are given pre-made components that fit the dominant use case for that device or platform. They are sheltered from the actual low level drawing, traversal, and animation primitives of the platform, which can be very tricky to use manually. On top of that, they are given strong direction about what kinds of UIs should be used for which platforms (Apple’s Human Interface Guidelines are a perfect example of this).
The web tries to be everything to everyone, and when it works it’s incredible. The problem is that it doesn’t do enough for specialized use cases like mobile apps (or game console UIs, or watch apps, or drones, for that matter). It’s too low-level.
For those needs, we should to look to frameworks that live and breathe their respective use cases. We should realize the web is this amazing, generic runtime platform, but it’s just that: generic. To really get the job done, we need to use specialized tools, and stop (poorly) reinventing the wheel.
If we do that, the web will stop “sucking,” and continue to dominate as the most widely used application runtime in the world, letting us focus on the unique problems that make our work interesting, and benefit from the help of millions of web developers from every corner of the world.
