Tag: Sencha

Categories
Tools

A Look at Some of the Top Mobile UI Frameworks

Deciding on a cross-platform tool (CPT) when developing mobile applications is really only the first step of a larger journey. When you choose a web-based CPT (PhoneGap, for example), you’re typically faced with the decision of what UI framework to choose as well.

Blog007-Final

The good news is that there are number of powerful options available. We’ll take a brief look at a few of these in this post. There’s a wide range of what’s available in a UI framework – some focus entirely on widgets (UI components), others provide light app framework functionality and still others provide a more comprehensive set of behaviors covering widgets and application framework concerns. The “right” choice for your project will depend largely on what you need, your team’s background and what kind of control you want to retain over certain aspects of the application architecture.

There are SO many interesting options, it can feel overwhelming even if you’re a veteran of HTML5-based mobile development. Limiting this post to only 4 frameworks was difficult. I will include a list of additional frameworks at the end in case you’d like to explore beyond the few we cover. If you’re looking for a full list of UI frameworks, check out the relevant section on ToolFinder – our online app for helping developers find the right tool!

jQuery Mobile

jquery-mobile

jQuery Mobile is arguably the most widely used mobile framework – benefiting from association with the nearly ubiquitous jQuery project. Due to its recognition and association with jQuery-based open source development, jQuery Mobile boasts a huge number of 3rd party plugins, extensions, tools, themes and more.

High Level Overview

Developers writing mobile and hybrid mobile apps using jQuery Mobile will encounter the following:

  • Heavy use of HTML “data-*” attributes. For example, a “page” in a jQuery Mobile application is simply a DOM element with a “data-role” attribute value like this: <div data-role="page"></div> Experienced web developers will pick up these kinds of framework conventions quickly.
  • jQuery Mobile provides a light application framework – primarily covering navigation, & transitions between views. This can be extended via plugins, or through integration with more comprehensive frameworks. If your “app framework” needs extend beyond transitions and navigations (for example, templating, two-way binding and more), jQuery Mobile alone may not be a good fit.
  • It’s designed to work within a Responsive Web Design (RWD) context – enabling developers to target a wide range of devices.
  • A wide array of device and browser support as well as a helpful theme roller to help with quickly customizing the otherwise “clone” look and feel.

Despite its popularity, jQuery Mobile has been criticized for performing poorly in mobile browsers. The jQuery Mobile team continues to work to improve the framework, including performance issues. If your team opts for jQuery Mobile, avoiding deeply nested DOM structures & unnecessary reflows and investigating the use of libraries like FastClick can help you avoid some of the typical pitfalls that have earned jQuery Mobile the “slow” label.

Widgets

jQuery Mobile’s site currently lists 22 built-in widgets (though the number of custom/3rd party widgets is much higher). Among them are header, footer, navbar, listview, slider popup and more (all the basics you would expect). Creating customized widgets is likely a moderate amount of effort for most developers. jQuery Mobile’s good documentation and examples will be helpful for any team. You can view a list of demos here.

The screen capture below demonstrates one of jQuery Mobile’s widgets: the responsive grid listview:

Licensing

jQuery mobile is free and open source (MIT licensed).

Kendo UI Mobile

Blog007-Final
Telerik’s Kendo UI Mobile framework has emerged as a powerful and performance-minded framework for mobile web and hybrid mobile applications. Kendo UI Mobile provides both UI widgets and app framework functionality. Kendo UI Mobile is part of a larger Kendo UI framework that can target both desktop and mobile devices. In addition, Kendo UI Dataviz is arguably one of the best data visualization libraries available for both desktop and mobile web clients*.

High Level Overview

Developers writing mobile and hybrid mobile apps will encounter the following:

  • Theming that matches the ‘native’ look and feel of iOS, Android, Blackberry and Windows Phone 8, as well as a “flat” theme that looks nice across multiple devices.
  • Similar to jQuery Mobile, Kendo UI Mobile makes use of HTML5 “data-*” attributes. For example, a “view” in a Kendo UI Mobile application is a DOM element with an attribute/value of ‘data-role=”view”‘. This naturally extends to Kendo UI Mobile’s widgets as well, since (for example) an unordered list element can be made into a “listview” element simply by adding ‘data-role=”listview”‘ to the element.
  • Two-way binding, with a declarative syntax. Kendo UI Mobile provides some fairly sophisticated application framework features, with MVVM (model-view-viewmodel) infrastructure included. Application state is typically maintained in ‘view models’, which are bound to views (DOM templates). As data in views change, the view models are automatically updated (and vice versa). By “declarative” we mean that the metadata necessary to enable two-way binding can be provided in the actual markup. For example, to bind the text content of a span to the “firstName” value of a view model, developers simply include this in the markup: <span data-bind="text: firstName"></span> Frameworks supporting two-way binding often help eliminate the same tired boilerplate code necessary in traversing DOM structures to retrieve state (user input, etc.). This can be a big productivity boost for your team.
  • Also included in the application framework features: view transitions, navigation & layout templates (which can be highly customized) as well as “DataSources” – an abstraction over retrieving data from multiple kinds of sources (for example, simple HTTP services, local data or even some Back-end-as-a-Service offerings). The Kendo UI team has gone quite a ways further than primarily UI/widget focused frameworks like jQuery Mobile in providing more substantial application architectural help.

Widgets

Kendo UI Mobile’s site lists 13 built-in widgets, ranging from ListView, ModalView, and TabStrip to Navbar (including support for header & footer), Drawer and Scroller (and more). Kendo UI Mobile supports creating custom widgets as well.

The screen capture below demonstrates a couple of Kendo UI Mobile’s adaptive widgets: the Grid and Scheduler. You can view additional Kendo UI Mobile demos here.

Licensing

Kendo UI mobile is a paid framework which starts at $199 (includes support for 1 year).

Sencha Touch

Sencha will be a recognizable name to many web & mobile developers – likely due to their response to Mark Zuckerberg’s assertion that “HTML5 Wasn’t Ready”. Sencha went on to prove that HTML5 is, indeed, ready for many complex use cases in mobile applications. Sencha Touch – Sencha’s mobile focused HTML5 development platform – goes much further than providing only widget-focused features.

High Level Overview

Sencha recently updated Sencha Touch so that their device APIs fully support Apache Cordova (i.e. – PhoneGap). Similar to Kendo UI Mobile, Sencha Touch makes use of HTML5 and CSS3 (taking advantage of hardware acceleration where possible) to create web-based UIs for mobile apps that aim to rival native UI performance. Developers building projects with Sencha Touch can expect the following:

  • Sencha Touch leans more heavily towards “full app framework” than many other popular options. It provides an MVC style architecture, complete with storage, device profile and top-level application abstractions.
  • Sencha Touch ships with 50 built-in components (and developers can create their own as well).
  • It’s my understanding that Touch shares some common code with ExtJS (and common conceptual paradigms), so developers familiar with ExtJS will pick things up quickly. I would also argue that developers used to frameworks like Backbone.js will also pick up the concepts more readily than developers used to UI frameworks that focus on declarative bindings in markup.
  • Sencha Touch provides its own abstractions for things like history management and XHR – which is in line with expectations of any framework seeking to be a more “one stop/full-stack” option.

Widgets

Components are a key part of Sencha Touch’s architecture. Among the 50 built-in components are ones such as Carousel, Slider, DataView, List, DatePicker and more. In other words – like the frameworks we’ve looked at so far, the essential things you’d expect plus a bit more. The screen capture below is showing some of the animation demos in the “Kitchen Sink” demo application, which highlights many features available in Touch:

Licensing

Sencha Touch has a wide array of licensing options (which can be seen here). It’s free for commercial use (and a GPLv3 option is also available). Sencha offers paid support options for Sencha Touch, starting at $1395 for a 5-developer package.

Chocolate Chip UI

Chocolate Chip UI’s beta debuted on Github roughly 3 years ago. Currently at version 3.0.6, the project has been gaining recognition as a powerful and performance-minded option for both mobile web and hybrid mobile applications targeting iOS, Android and Windows Phone 8. Chocolate Chip UI’s site lists 12 widgets, but simply skimming the documentation will reveal many more. Chocolate Chip UI provides a substantial amount of UI/widget focused features, but also ventures somewhat into “application framework” territory by providing a number of utility methods & view transition features – though it stops short of client-side routing (though there’s nothing preventing you from integrating any number of routing libraries).

High Level Overview

Developers using Chocolate Chip UI will encounter the following:

  • Chocolate Chip UI makes use of semantic HTML5 elements to drive its widgets. Your team may find overtime that this aids markup readability.
  • Chocolate Chip UI encourages the use of their own JavaScript library (ChocolateChip.js) in lieu of jQuery. They maintain that it was created specifically for mobile use and that it is both faster and smaller. It is possible to use jQuery 2.0.3 on Chocolate Chip UI version 3.0.3 and newer. This may prove useful if your team has jQuery plugins which are essential to the project.
  • Chocolate Chip UI provides API hooks to create your own widgets which follow the same paradigm as creating jQuery plugins. This will aid your team’s transition from jQuery to ChocolateChip.js.
  • Chocolate Chip UI uses OS-specific theming, allowing you to target a specific mobile platform (currently iOS, Android and Windows Phone 8) simply by sourcing the appropriate CSS file.
  • Chocolate Chip UI provides layout behaviors to help organize your DOM structure, as well as a number of utility methods including script loading, type testing, string utilities, AJAX communications and more.

Widgets

As mentioned above, Chocolate Chip UI’s home page lists 12 widgets – among them things like Popup, Paging, Range, Switch and multiple types of Lists. However, as you review the documentation, you’ll notice mention of additional widgets such as slide out menus, masks (semi-transparent overlays), split layouts (for tablets) and more. You can see a few of these in the screen capture below (specifically, range/slider and pop-over):

Licensing

Chocolate Chip UI can be licensed either under BSD or commercially. For commercial terms, you need to contact Sourcebits to get a quote. I reached out to Sourcebits to get more information on commercial licensing, and they were very prompt & friendly in replying:

“…our terms for commercial use are an acknowledgment that Sourcebits’ Chocolate Chip UI was used in the creation of the app, something along the lines of “Powered by Chocolate Chip UI”, either in the app’s splash screen or ‘About’ page with tap/link back to ChUI’s awesome landing page, as well as permission to use the brand’s name/logo on our website. In addition we might also wish to collaborate with the brand to create a case study around their use of ChUI. We’d have the same asks if a ChUI web app were being deployed for internal use by an enterprise, too.”

Further Resources

Markus Falk has a fantastic mobile frameworks comparison tool which you may find quite useful in evaluating which options will work for your team. One thing to bear in mind: this comparison chart doesn’t differentiate between UI frameworks and cross-platform tools (like PhoneGap), so it’s useful if you’re looking up supported features for a given framework or comparing two frameworks of the same type (i.e. – apples-to-apples comparison of two or more UI libraries, or CPTs, etc).

Also – check out our own full listing of UI frameworks, on our ToolFinder web app,

This post can’t possibly cover all the UI framework options available – and choosing which ones to write about was extremely difficult, given the amazing number of good choices out there. I’d like to list a few more here to give you the option of further exploring which UI framework(s) may work best for you. Bear in mind that these are web-based UI frameworks for mobile web or hybrid mobile solutions that make use of web-based assets (like PhoneGap):

Have you used any of these options? If so, we’d love to hear about your experience. Feel like one is missing? Let us know! We’d love to hear what you’ve been using.

* I’ve used Raphael and D3.js – and love both (not to mention, both are free frameworks). I think very highly of Kendo UI Dataviz primarily because of the wide browser support (it uses canvas, SVG and VML, depending on the browser) and because of the accessible/intuitive API.

Categories
Tools

Pros and Cons of the Top 5 Cross-Platform Tools

As the market temperature for cross-platform tools (CPTs) continues its steep climb into hotter territory, it’s understandable why many feel we are witnessing a mobile fragmentation that is perhaps much larger and more significant than the recent wars waged over the desktop. If this fragmentation tells us anything, it’s that [tweetable]cross-platform tools for mobile development are often not a “one-size-fits-all” solution[/tweetable] – and that there are numerous veteran users of these tools that do not believe the problem has been solved as well as it could be….yet. In our Developer Economics Q1 2013 report, the breakdown of the top CPTs looks like this:

18-01

How many of these tools do you know? Test your skills in the new Developer Economics Survey and win awesome prizes.

As you’d expect, each approach comes with trade-offs. Let’s examine the top five cross-platform tools (PhoneGap, Appcelerator, Adobe AIR, Sencha, Qt), as identified in our research, and list out the more salient pros and cons of each. This is not an exhaustive list, of course, as each platform can’t be explored in depth in one post alone. Want toexplore more cross-platform tools we’ve identified? Check out the CPT section on our ToolFinder tool atlas

Apache Cordova/PhoneGap

Apache Cordova (known by many as “PhoneGap“) holds the top slot in developer mindshare. Cordova/PhoneGap developers write their mobile applications using HTML, JavaScript and CSS. These assets run in a “WebView” inside a native application container on the target platform. It is, conceptually, a web application packaged within a native application container where your JavaScript has access to device-level APIs that normal web applications would not (more on that below).

The name “PhoneGap” is quite possibly one of the more recognizable names in this space. Originally created by Nitobi, the name was changed to “Apache Cordova” when it was donated to the Apache Software Foundation. Adobe purchased Nitobi – including rights to the PhoneGap name – and now distributes Cordova under that name.

Pros

  • Regardless of server side platform & language experience, a significant number of developers have experience with HTML, JavaScript and CSS. Apache Cordova allows developers to immediately leverage these existing skills. The value of this can’t be overstated – as it reduces training and can enable a quick-to-market stance in companies ready to adopt it.
  • Cordova apps install just like a native application, and are able to leverage app store discoverability.
  • Cordova follows a plugin architecture, which means that access to native device APIs can be extended in a modular way. There are a lot Cordova/PhoneGap plugins to choose from – enabling developers to focus on the web-based skills they already have. (This is a weakness as well, as we’ll see in a moment.)
  • Cordova is open source and free, so there are no licensing costs (also a potential weakness, mentioned below).
  • Cordova/PhoneGap solutions existed in this space early on, and have matured to the point where value-add offerings on top of the basic CPT are the norm. For example, both Adobe’s PhoneGap Build and Telerik’s Icenium enable developers to build for supported target platforms in the cloud, without local SDKs (meaning non-Mac users can build iOS applications). In addition to Icenium’s cloud build services, Telerik also provides Kendo UI Mobile (an MVVM framework targeted for performance on mobile), app analytics via EQATEC and a Backend-as-a-Service (BaaS) offering named Everlive. Adobe has integrated PhoneGap Build capabilities into Brackets (a web based IDE) and Dreamweaver.

Cons

  • Of course, being free is no guarantee of success. In fact, the emergence of PhoneGap Build and Icenium are clear demonstrations that a “bare bones” Apache Cordova is woefully incomplete. The strength of being open source – and leveraging the talents of a wide array of contributors – is both a blessing and curse. If you need to extend your app with a custom Cordova/PhoneGap plugin, odds are you will find one. Yet it may be out of date and not support the target platforms you need.
  • The plugin architecture works well if you can find the plugins you need or if your web developers are capable of changing gears to write their own custom plugin(s) as needed. However, odds are that you chose Cordova, in part, to avoid the need for specialized native platform skills.
  • The performance of Cordova/PhoneGap apps has often been criticized. Native UI will always outperform a hybrid solution, but improvements in device hardware and WebView implementations have narrowed the gap. Your web developers will need to pay close attention to performance, which means their knowledge of profiling tools as well as which web UI frameworks are mobile-friendly is essential.

Appcelerator

Appcelerator’s Titanium provides a unified (across devices) JavaScript API, coupled with native-platform-specific features. Developers write JavaScript and utilize a UI abstraction (the Alloy MVC framework) that results in the use of native UI components, greatly aiding UI performance compared to other hybrid options.

Pros

  • The use of native UI components is a performance win, and the Alloy framework attempts to normalize UI across platforms.
  • The use of JavaScript to normalize code across platforms enables you to leverage existing skills on multiple target platforms.
  • Appcelerator provides value-adds such as a Backend-as-a-Service (BaaS), app analytics and a marketplace for 3rd party components.

Cons

  • Developers are required to manage target platform SDKs locally. It’s highly recommended for your team to establish a controlled build environment/CI process if you choose to manage SDKs locally, especially if you target multiple platforms. SDK version & build-related issues can be a horrific time sink, when you really need your team delivering features.
  • Normalizing the UI across platforms, while arguably a “pro”, is also a “con” in that your team will need to train on a proprietary technology to gain skills that are not directly transferrable outside Titanium.

Adobe AIR

Adobe AIR is “a cross-operating-system runtime that lets developers combine HTML, JavaScript, Adobe Flash® and Flex technologies, and ActionScript® to deploy rich Internet applications (RIAs) on a broad range of devices including desktop computers, netbooks, tablets, smartphones, and TVs.” The problem with that description is that you cannot use HTML & JavaScript to write Adobe AIR applications for mobile applications (Flash/ActionScript skills need only apply).

Pros

  • Adobe AIR has impressive reach – running on a wide array of desktop and mobile devices. In addition, if you plan to have a more involved/animated UI (and don’t plan to use a native approach), using AIR over a HTML/JavaScript/CSS approach may help.
  • Most Flash/ActionScript developers consider the IDE tooling for these technologies as mature.

Cons

  • The “elephant in the room” for many mobile developers is the fact that Adobe purchased Nitobi (and the rights to the PhoneGap name), clearly signaling to many that AIR may not be a long term strategy for mobile development. This combined with the rapid decline of Flash erodes the confidence many developers might otherwise have in choosing AIR.

Sencha

Sencha Touch is an HTML5 mobile application framework for building web applications that look and feel like native applications. Apps built with Sencha Touch can be used with Apache Cordova/PhoneGap or Sencha’s native packager – either which will package the application in a native container and enable access to select device-level APIs unavailable to traditional web apps.

Pros

  • Sencha have produced a larger quite of interoperable products, from “Sencha Architect” (a visual HTML5 app builder) and “Sencha Touch Charts” (for data visualization) to IDE integration with the Sencha Eclipse Plugin and an secure Enterprise app deployment story with Sencha Space.
  • Sencha Touch offers an MVC style architecture, a library of UI components, an extensible API and UI themes among other features.
  • Native packaging is possible via Apache Cordova/PhoneGap or Sencha’s SDK.

Cons

  • Mobile apps written with Sencha Touch can suffer from the same performance pains as Cordova/PhoneGap apps if developers aren’t disciplined in writing efficient JavaScript and DOM structure(s).
  • Many developers already have established opinions and experience with preferred frameworks for building HTML5/JavaScript/CSS based apps. Sencha’s emphasis on its own stack will be perceived as vendor lock-in.
  • Extending a Sencha Touch app with access to additional native APIs will likely involve writing custom Apache Cordova/PhoneGap plugins. This will require specialized platform skills (or training to acquire them).

Qt

Qt (“Cute”) is a cross-platform development tool that targets a number of embedded, desktop and mobile platforms. Developers write using “QML“, touted as a “CSS & JavaScript like language”, and apps are backed with an extensive set of C++ libraries, and utilize graphics/UI components written in C++. [UPDATE: As clarified by @qtproject, “Qt exists as a free and open source version from @qtproject and a commercial offering on top, from @QtbyDigia“]

Pros

  • Qt provides a substantial set of libraries containing intuitive APIs for things like threading, networking, animations and more.
  • Qt’s IDE tooling (Qt Creator IDE & Qt Designer) appear to be solid development tools, and code profiling is available in QML Profiler.
  • Qt Linguist enables translation and internationalization in applications – giving you the support of multiple languages within your app (in a single binary).

Cons [updated thanks to new information from Digia]

  • Qt’s tools are advertised as a “complete tool chain”, and QML is a proprietary language specific to Qt’s stack. Committing to this approach could be seen by many companies as ‘platform lock-in’, given that most businesses are seeking to re-use existing skill sets when adopting a CPT, not fragment skills further. (The leap from JavaScript to QML may not be as far as a leap from web-based skills to Objective-C, for example – each team just needs to evaluate what it can handle).
  • [Updated] Originally we listed pricing as a “con”, since full commercial support could exceed €4,000 (this includes plug-in development, platform development, device modification as well as unlimited support and updates). The cost of this kind of support is significantly higher than support costs for the other CPTs we’ve looked at. However, Digia reached out with a link to the recently announced Qt Mobile Edition. According to Digia the monthly fee will be $149 (approximately €110) and will launch in the coming weeks after the release of Qt 5.2.  This pricing level puts Qt’s mobile development costs more in line with the alternatives we’ve discussed. (It’s also important to note that Qt supports an open source LGPL v2.1 license.)

Reality: You’ll Probably Use More Than One

In our Developer Economics 2013 report, we noted the following:

Developers most often use several cross-platform tools; on average CPT developers will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our dedicated CPT survey just over a year ago. Moreover, we found that one in four developers will use more than three cross platform tools.

What CPT(s) do you plan to investigate or adopt? Check out the full list of CPTs we’ve identified.

 

Which of these are your favourites?  Test your skills in the new Developer Economics Survey and win awesome prizes.

Categories
APIs Tools

Accelerating Web Apps – It’s all about politics

On desktop computers web apps have come to dominate many application categories. They are easier to develop and deploy across multiple platforms and it’s possible to iterate much faster. A very large number of developers would like to be able to apply the same technologies and techniques on mobile devices but very few are able to do so successfully, particularly for mass market consumer apps. One of the most important reasons for this is performance. Resolving this issue is much more about politics than technology.

Are mobile web apps doomed to be slow?

Back in July, Drew Crawford wrote a blog post that got a lot of attention essentially claiming that JavaScript performance on mobile devices was simply too slow for serious apps and likely to stay that way for the foreseeable future. It showed, amongst other things, that the browser on the iPhone 4S was around four times slower than the slowest browsers capable of running Google docs real-time collaboration or Google Wave back in 2010. He claimed that ARM processors were not going to get faster rapidly enough to make a difference and JavaScript runtime improvements had stalled and were unlikely to make significant progress. Technically both of these points seem to have been proven wrong already. Apple just announced the iPhone 5S, with a processor twice as fast as the iPhone 5, which was in turn twice as fast as the iPhone 4S – so we have four times more raw CPU performance than we had just two years ago, theoretically enough to support 2010 desktop class browser performance. Also, Mozilla are working on asm.js, which uses a subset of JavaScript compiled ahead of time (AOT) and promises to enable apps to run in the browser at just 1.3 times slower than native performance – almost another four times speed increase versus the current five times slower than native performance of modern JIT compilers.

In addition to being at least partly incorrect this is also looking at a very narrow area of browser performance, a point well made in Sencha’s blog post in response. Across all vendors there are key performance areas where each is 10-40 times behind another. In reality, most of the major performance issues that prevent web apps from being competitive with native apps are related to graphics performance. Mobile device users have come to expect slick animated UIs which are only enabled by GPUs on the devices rather than, say, manipulating the DOM with JavaScript. Fortunately HTML5 and CSS3 provide several opportunities for GPU accelerated graphics with e.g. Canvas, CSS animations and WebGL. So, as mobile hardware and browser software continue to improve over the next couple of years competitive web apps should be just around the corner, shouldn’t they?

Platform wars and politics

With the technologies available or on the very near horizon today, plus improvements to mobile browsers across the major platforms, there’s almost no doubt that we could have competitive web app performance. The problem is that to get there requires platform providers and OEMs to adopt the technologies and implement the improvements – it’s not necessarily in their interests to do so.

Apple and Microsoft want users locked-in while Google wants them logged-in. Mozilla wants the open web everywhere but Google funds them. Opera recently gave up on writing their own browser core and use Google’s instead. That’s over-simplifying but fairly accurate. With other browser vendors attempting to prevent the user tracking that Google’s business model depends on (through default Do Not Track settings or third party cookie blocking) the best way to ensure users stay logged-in is to get them all using Chrome. This means they’re fighting a new browser war for control of the desktop web and taking that to the bulk of the mobile market through Android. In the process they are building several browser technologies to differentiate rather than standardise (e.g. they’ll prefer their own Native Client solution to asm.js).

At the same time Apple wants a great browsing experience but wants developers to build native apps rather than cross-platform web apps. As such they adopt most new web standards quickly but are very slow to include any that might enable high performance web apps – e.g. WebGL has been implemented since iOS 4.2 but only enabled for iAd, not in the browser, also Apple has famously not enabled their JIT compiler in the WebViews used by wrapped web apps* (needed to access native APIs) slowing their JavaScript performance by almost four times. Mozilla’s asm.js seems a very unlikely candidate for Apple to adopt anytime soon. Unless their new CEO makes a major change of strategy, Microsoft seem determined to follow the Apple model, although they might need first class web apps enough to accelerate their standards adoption.

A ray of light?

While there may be several classes of app for which mobile browsers are already good enough, for those hoping to develop all apps with web technologies, the news is not all bad. Although it seems unlikely to be possible to deliver a single solution with great performance everywhere, we might not be far from being able to deliver a good level of performance almost everywhere. Although Apple appear to have some strategic performance limitations, they also have some of the fastest hardware on the market. At the other end of the spectrum good Android browsers are reaching low end smartphones and the Firefox OS, also targeted at low cost devices, has an excellent web app environment. The other good news is that while we have real competition in the mobile market, browsers should keep getting better all round. We’re unlikely to see the return to stagnation of the Internet Explorer dominated early 2000’s.

* Apple do have a good security reason for doing this but they haven’t been in a hurry to resolve it either.

Categories
APIs Languages

Websites vs Web apps: What the experts think

websites-vs-webapps

Definitions of web sites vs. apps

Web sites are so deeply embedded into our daily culture that it is impossible to imagine life without them. Even as a developer, I find it hard to remember the times from my childhood when my chubby little hands didn’t yet know how to type. In the last two decades, the Internet has grown, expanded, exploded and became impossible to ignore, making any keyboard without an Internet connection pretty much useless.

In the last few years, the web brought with it a new term that can be exciting and confusing at the same time: “web app”. But what is a “web app”, how does it differentiate from a “web site” and why does it matter?

Understanding this difference ultimately makes us better users or developers? Is a business going to blossom just by marketing its online presence as a “web app” instead of a “web site”?

To figure out the boundaries between websites and web apps, I interviewed several prominent figures in the web technology domain who contributed with their experience and professionalism to help guide the debate: Dominique Hazael-Massieux (Mobile Web Initiative Activity Lead at World Wide Web Consortium), James Pearce (Head of Developer Advocacy at Facebook), Michael Mullany (CEO at Sencha), Christian Heilmann (Principal Developer Evangelist – HTML5/Open Web – at Mozilla Corporation) and Stephen Pinches (Head of Learning Technologies – ELT at Pearson plc and Group Product Manager – Mobile & Emerging Platforms at Financial Times). In this article I pieced together their expert input to help answer the web site vs web app debate.

The difference between Web sites and Web apps

In the pre app store era, the word “applications” had been applied to Web sites that provided advanced user interactions and capabilities previously available only through installable software. Early examples of web applications include Webmail, Google Maps and Google Docs. Compared to the classic web, i.e. blogs and news sites, web apps provided a richer user experience and access to advanced browser capabilities.

Today single-page web sites might still be referred to as web apps, but it’s more about the task focus than the technology itself. From this perspective, as Christian Heilmann explains, “The use case of an application is always to DO something with it”.

The task centricity of web apps is easier to understand if you think of smartphones or tablets: an app’s purpose is to achieve a specific task, like making a call, checking your email or finding a taxi nearby.

Some may argue that we can simply classify Web sites as being read-only and Web apps as being read-write. That certainly seems simple enough: Web sites are for consumption what Web apps are for creation. Does it sound right?

For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts:

  • self-contained
  • rich/interactive user interface, possibly mimicking the native UI of the device,
  • using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing,
  • action oriented rather than information oriented
  • not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar),
  • working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database.

Mozilla’s Christian Heilmann argues that the offline attribute is not a technical necessity in terms of definition, but rather a crucial usability distinction:

“Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online”.

But how can we explain the difference to non-technical users? And, do we need to?

According to Dominique Hazael-Massieux, a Web site can be presented as a Web app as long as users consume it in a similar way they do a native app. If it’s exposed as an iconified app and used for a specific task, it shouldn’t matter whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web apps. I‘ve summed up his arguments:

Creation versus Consumption

Pearce asserts that read-only interaction should be classified as a site, but this criteria is not sufficient to distinguish between web sites and web apps. We still have cases like Flipboard (clearly oriented towards consumption) or Twitter and Facebook (with entirely user-generated content) that do not fit in any box.

Linkability

Since both web sites and web apps can be launched by entering a URL into a browser or from a home-screen icon, this is clearly “not a reliable way to distinguish between web apps and web sites” according to Pearce.

User Experience

Visual pizzazz is an important argument, one that users might particularly relate to, but is also a fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list appears as hyperlinks instead of ‘tappable’ items? What if I use plain scrolling instead of smooth fancy bars?

Architecture

In the case of single page webapps, is SEO the price to pay when choosing to give the browser far more autonomy and responsibility and take advantage of its HTML5 APIs like storage? Do Web sites have SEO capabilities while Web apps don’t? We are back to explaining the differences between the two by using technical terms.

Should you be building web apps or web sites?

This question might be regarded as a technicality with a pinch of marketing to spice it up. This reminds me of the “HTML5 is ready” contest by Sencha that was announced a few months back, encouraging developers to draw inspiration from native apps and create similar web apps that show off the capabilities of HTML5.

The creators of the competition correctly argued that “the mobile web is the most fertile ground for leading edge web development because it doesn’t have the legacy of the older internet explorers that the desktop does. You can start your development with the assumption that your app or your content will be used in a fairly recent browser, so you can take advantage of a whole host of features like Canvas, inline SVG, HTML5 video, CSS3 styling etc. that bring the experience alive for the user”, as Sencha’s Michael Mullany explains.

Would it be safe to argue in favour of building web apps instead of web sites especially on mobile? Mobile users perform specific tasks on their devices, so a web app that offers the same experience as a specialised native app might gain more interest compared to a regular website.

Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.”

The ‘app-ification’ of the Web

Whatever your preference may be, there is an increasing number of mobile developers targeting web apps. Based on VisionMobile’s latest Developer Economics survey of 6,000+ developers, already 23% of HTML5 mobile developers develop web apps, compared to 38% who develop mobile websites.

With browsers increasing support for device APIs, and with a growing number of developers going direct to native with PhoneGap, Icenium or Appcelerator, or even with the recently launched Firefox OS, the web world is clearly moving in the direction of apps.

As Sir Tim Berners-Lee said in 2012, “the solution is in your hands: develop web apps!”