Getting Cozy With WebViews, Part 1
Getting Cozy With WebViews, Part 1
Get your favorite blanket, a cup of hot cocoa, and curl up with some WebViews! It warms my nerdy little heart just thinking about it.
Join the DZone community and get the full member experience.Join For Free
The browser engines, as well as the hardware components in smartphones, have dramatically improved in the last decade. The web platform has also standardized many APIs required for mobile development. Network bandwidths have had a major uptick. Just like Electron in the last 5 years has become the standard way for developing desktop apps, the time is ripe for web technologies to put the strong foot forward in mobile app development.
Web Views Are Out of Fashion
WebViews were vogue in the early days of mobile development. The original iPhone had support for pinning websites on the home page and that was the only way to add applications to the device. There was no App Store and no native development. By 2009, everyone was building a mobile version of their website optimized for smaller screen sizes. PhoneGap was a new and promising technology that could make mobile development easier by helping us write once and use multiple times — the same software could run on the iPhone, Android, and the upcoming Windows phones. Even in the App Store, many apps were wrappers placed over the website to get an entry in the search results.
Most major applications moved off WebViews from 2011-2012 for a variety of reasons:
- The web was a document delivery platform and even things like vertical centering required extensive hacks.
- There was no web app and most websites were rendered on the server and the building blocks of web apps — JSON support, Flexbox, and media queries were absent in most browsers.
- There were too many mobile platforms - Blackberry, Symbian, and Windows Mobile still existed. While the native app developers were happy to optimize for the specific platform, web apps were sold to the executive team as the solution that was cross-platform. Therefore, they had to support the most incapable platforms on the website and the quality suffered.
- Mobile was rapidly evolving - There were significant changes taking place with every passing year. From the release of the iPad to Retina displays, while the native developers got tools for each and every change, web developers who needed to support older devices were stuck with the minimum common set and the platform itself took time to catch up.
- The web carried a lot of baggage - Most apps were fresh code bases written from scratch to support a new platform. Many web apps were patches over existing 5-year-old projects written for IE6 support. The re-engineering and removal of defunct use cases made native apps thinner and lighter.
- Tooling was not there - Remember Firebug? That was a huge luxury to have. Without it, developers resorted to alert-based debugging where a modal dialog was launched just to print a string, especially on the Android Browser (no Chrome on Android back then). Many web developers used notepad and did not have a compiler, linter, or a code formatter. Selenium was in its infancy and was mostly a hack of injecting scripts to provide a testing environment on desktop.
- The big churn - The web community was going through the biggest churn in code and practices. Flash -> JQuery -> Backbone -> Angular -> React all in a span of a few years. Browser wars 2.0 was in full rage and there were new features out every month that made old web development practices defunct.
- The web got bad press - Mobile surprised a lot of giant technology companies and they were unprepared. Facebook put the blame on web technology. That, too, just before their hugely anticipated IPO. It became extremely difficult to defend web once one of the biggest technology companies publicly shames the platform in the general media.
- Design practices were evolving - Mobile was new and the best practices on mobile were still evolving. Here is an image of The New York Times from the Blackberry days. 50% of the screen space was the header and the footer. That, too, on the smaller screens that we had back then. Shrinking the desktop design on mobile, we know now, was not the best solution. Even though the web might have been easier to experiment with for new designs, native apps mostly got the new designs first simply because the web was the last resort for the extreme edge cases — no one wanted to risk the users who expected the desktop functionality on mobile.
You might have realized almost all of those concerns are not there anymore. The core features required for mobile development have been stable in the web browsers for years and even the oldest browsers in use support most of the essentials. There are just two mobile platforms left and even they have been converging. People are holding onto their phones longer and most apps do not need to support all of the new features. Most apps are more than five years old and carry similar baggage to the web. With ES6, many web apps are getting a reboot. Tooling on the web has left native far behind. The web platform has stabilized.
Array.includes is not a huge change in comparison to
class statement and we still get the same buzz because there is not much new to cheer about. Native has had its own share of churns: Objective-C to Swift, the removal of 32-bit apps and OpenGL, and the migration from Eclipse to Android Studio. There has been radical unification of design. Most apps look the same on Android and iOS. The differences, like menu placement, are minor. Many apps have started building their own conventions that are cross-platform and many developers, instead of building platform only features, have been busy ensuring the design remains consistent.
Web Has Quietly Surpassed Mobile
For building a regular application on mobile, web platforms provide better features today than native code ever did:
- Live Reload - The web stack is much easier to develop due to live reload. Change something and see it live. Add in the fact that you can debug mostly on the desktop browser and things work fine on mobile. Native never had this luxury in the past and may never have it in the future.
- Layout - CSS Grid and Flexbox are much more expressive and powerful than auto layout ever was. As an added advantage, there is no interface builder where you cannot do diffs across checkins or merge changes across commits.
- Hot patches - The web as a platform has been built online and offline capabilities were added later. Adding online capabilities and network conditions is many times more difficult than adding offline caching. Minor fixes do not need a huge cycle for submitting an app for review and watching it slowly being adopted. If built right, the web-based app can be updated almost instantly for most users.
- Testing and CI/CD - Testing web-based code is many times easier than testing native apps. Tests can run extremely fast with the command line and on the automation machines. That makes them extremely easy to use. Setting up a build machine for automating native apps is so much effort that many teams decide to skip it altogether.
- Code sharing - This has deliberately been put as the last item. Web-based apps can share some code between multiple platforms and even with the server and the website. This can turn into a huge limitation if we developers go overboard with supporting everything.
That's all for Part 1! Come back tomorrow when we'll be discussing some ideal app ideas and how WebViews impact native development.
Published at DZone with permission of Atishay Jain . See the original article here.
Opinions expressed by DZone contributors are their own.