With the imminent release of Foundation for Apps, we've been chatting a lot about apps and how they're built. We've discussed the topic internally with our team, externally with our clients and with tons of our amazing ZURB friends. Much of that discussion revolved around not just how to produce apps, but what an app really is, how they differ from websites and even the future of where they'll go.
Before Apps There Were Applications
In the early days of computers, apps — or applications as they were once known — were pretty much the entire computer experience. You'd take a physical object, such as a floppy, put that in your computer and then use the digital version of the application. It was amazeballs. With the emergence of the internet, we saw people attempting to take what was once reserved for operating systems and move it online. CGI Applications like Hotmail created services that a user could access virtually from any computer in existence. And a flood of applications followed suit. Web apps became as commonplace as desktop applications in the early aughts. Users no longer needed to fire up Word or Excel to create simple documents, and instead turned to the web where they could collaborate with others on documents and spreadsheets.
By the mid to late 2000s, web apps had become fairly ubiquitous in everything from email to CRMs to photo editing. Everything that could be done on the web was being done on the web. Then, along came smartphones and more importantly the invention of the App Store. Suddenly apps were being downloaded like it was 1999, and a resurgence of operating system-based apps were once again upon us.
Native Apps Like It's 1999
Don't get us wrong. The App Store is great. It provides easy access to an entire platform for users. It's (mostly) easy to find apps and most importantly the app store has a built in revenue model. It just poses several problems when thinking about creating a business around applications. Apple's App Store and, to some extent, Google Play, are closed systems meaning they control what is allowed on their turf. This becomes a dangerous game of monopoly where they can easily prevent you from passing go or collecting your $200. They can deny your app if it's too similar to something they are in the process of creating themselves. The web, on the other hand, is an open system where anything is allowed to thrive and to make money, for better or worse. If the web is the Wild West, then the app store is Disney's Frontierland. Sometimes we need to go back west.
Build Once Work Everywhere, Anywhere and for Anything
ZURB has been a huge proponent for responsive web design, pretty much since good ol' Ethan Marcotte coined the term in 2010. Responsive was everything our clients wanted, but didn't know they needed. Never again would we be responsible for creating a slimmed down version of a web site to use on mobile devices. Never again would we be responsible for maintaining several, separate code bases. We even created Foundation, the first fully responsive framework, to make our lives and many other ones easier.
Mobile native apps have reached a point in their lifecycle where what was once one or two screen sizes is now dozens, and what was once maybe several devices is thousands. Yet native apps are struggling with the bridge from mobile experiences to desktop ones. This means a company must create applications for iOS, Android, Windows mobile, Amazon Fire and even OS X and Windows for desktop — all with different screen sizes and orientations. That's dozens of code bases and tons of tweaking, only to be foiled every time a new device size is released or a new OS is introduced.
There's gotta' be a better way! Hey, wait, there is!
The State of the Web App
The last four years of the web have moved pretty quickly. We're finally reaching a place where the web is catching back up with native platforms. There are several neat advancements that are helping us do this and we wanted to talk about several of them.
Layout
Layout has been a huge issue because most of what makes up web pages hasn't changed in years. The majority of the web still uses floats, which were never intended to be anywhere near as responsible for layout as they ended up being. Something that was originally intended to push an image left or right has become the basis of almost all the layouts out there. There are some new contenders to the layout debate, so lets take a look:
- JS Layout: Many current web apps use tons of JS to position layout items and make them respond how we'd wish the web would. This has worked OK, but is heavy and falls almost completely apart when attempting a responsive layout.
- CSS Grid: Believe it or not this is the first time we have a property in CSS that's completely focused on layout. CSS Grids will replace much of what we've done with grid systems. Unfortunately, this has yet to be implemented completely (or at all, really) in any browser, so for now it's just a pipe dream.
- Flexbox: While not specifically for layout, Flexbox lets us do some neat things with positioning and order. Flexbox allows to easily position items next to each other and mix fixed with fluid widths. It will never force us to clear a float again. Flexbox can still be hard as heck to understand, but we've chosen it for Foundation for Apps and help abstract most of that, so it has that going for it.
Speed
Speed is a tricky one as we don't control a good majority of that equation. We can assume a user has wifi or 4G, but at any moment they might not. Not to say this is just a web problem, since a good amount of native apps rely on internet connectivity to access data. The speed we're looking to match here is the speed of actions and the fluidity that goes along with that.
- SPAs: The popularity of the Single Page App web frameworks has been a really huge step forward for web apps. You can tell how many because there are TONS out there and more coming out every day with really awesome names like Ember, Angular and even Batman. These help give apps that fluid feeling and cut down on the dreaded page reload.
- Local Storage: An ever-increasing number of browsers are giving us access to local storage to save and cache files that would normally need to be loaded each time the app was visited. This isn't the same as downloading an entire app, but with most major browsers giving you anywhere from 5'10MB of storage you can often speed up load time pretty drastically.
- Application cache: All major browsers now support application cacheing, which is huge for creating web apps that can function offline. Some actions may work, but much like their native counterparts most actual data will require a connection.
Distribution
Applications went from a physical store distributed by a third party, to a download from the creator, back to a digital store operated by a third party. In fact a 2011 Neilson study showed that 63% of users downloaded apps because they had found them solely on the app store. With web apps, we need to rely on our own marketing prowess and distribution model.
- Web App Stores: Google seemingly has one of the only reliable web app stores in existence. They've done a great job with its web app store and has many of the same features of a native store, but solely for HTML5 web apps. There are several other app stores out there, like BestVendor or Listio. However, these stores have had limited success with the average user.
- Marketing Sites: Web apps are perfect for marketing sites as they can sign up and go straight to the app, no need to be directed to a third party site or leave your browser. They're great places to fully explain your product and get users truly excited.
On The Outside Looking In
We're still not living in a perfect world for web apps. We don't always have access to all the 'goodies' native apps have access to. This means that, for now at least, some specific ideas or industries may be hindered from using web apps based on the technology they have access to.
Desktop-based web apps are in better shape than mobile ones. That's because most browsers allow the user to tap into native notifications, which can really help bring users back into an app. Desktop browsers are very optimized for the JS and loads that come with web apps. It appears one of the only things native hasn't done is allowed web apps to operate as icons in the doc or in their own independent windows. This is a hurdle we can hope to achieve soon.
Mobile devices haven't fared so well. For one, because mobile devices tend to be less powerful with less reliable access to high speed internet. Secondarily, because these manufacturers have little to no reason to end their control over the apps users have access to. Web apps on mobile devices do have the luxury of saving apps onto the home screen, but beyond that they suffer pretty deeply. No access to push notifications, the camera and many of the other peripherals become super problematic for web apps.
For example:
- Instagram: would have never existed without access to the camera
- Games (most of them): need access to the devices gyroscope
- YO: May never have existed (God forbid) without push notifications.
There are still tons of things left until web apps have all the tools native apps do, but every new release of iOS or Android we see more and more access opening up. APIs and code libraries are evolving that could solve these issues for web apps — accelerometer, GPS control, camera control, HTML5 local storage. Our friends at Treehouse have put together a great list of features that are available now and it's pretty exciting what the next couple of years bring.
For Now We Dream
At ZURB we think consumers and developers are at the precipice for figuring out responsive web apps and we just love the potential shift back to an open platform. We're building Foundation for Apps and we expect tons of people to build apps that blow our minds. We know that even though the technology is not yet perfect, the only way to get the Apples and Googles to change their mind is to drive the need for change. Let's all start to drive that need.