Rethinking What We Mean by ‘Mobile Web’
daringfireball.net
daringfireball.net
"We should think of the web as anything transmitted using HTTP and HTTPS."
Which unfortunately, because there's hardly a single modern internet application or service that doesn't or can't run over HTTP(S), it inflates the definition of "web" to be so broadly inclusive that it becomes an altogether meaningless term.It may be his intention to position native "apps" as something not in opposition to, but rather a part of, the web. But that does a disservice to the original meaning of the web, which thrived in large part because it wasn't just another native app connected to the net.
Instead, I'd recommend pushing back a bit, and trying to retain the other critical elements of what made the web the web, such as transparently introspectable formats, RESTful documentment-oriented architectures, hyperlinkable URLs, crawlability, freely-licensed and open protocols, etc.
> It’s possible that the word “web” is too tightly associated with HTML/CSS/JavaScript content rendered in web browsers — that if I want to make a semantic argument, I should be saying it’s the internet that matters, not the web. But I like calling it the web, even as it expands outside the confines of HTML/CSS/JavaScript. The web has always been a nebulous concept, but at its center is the idea that everything can be linked. So when I open Tweetbot on my iPhone and tap a link that opens within the app as a web page, and from that web page tap a link that opens a video in the YouTube app — that to me feels very webby.
It's almost like he addressed the exact arguments you guys are bringing up in the article linked above...
He makes his definition of what the web is very clear, and cites his reasons behind them. You might disagree with them, but he does actually address them, to his credit. Perhaps you might make an argument why your definition of the web is superior to his.
The vast majority of native mobile apps are not. See http://www.apple.com/itunes/charts/paid-apps for a good list of counter-examples.
The biggest problem I've found with mobile apps built with browser technology, personally, is that they often give none of the affordances of a native app and none of the affordances of the web. They become so obsessed with poorly aping native technologies* that they often fail to play to their strengths - things like deep-linking, tabbed browsing, lightweight usage, hypermedia, and so on. I don't really get it.
I suspect that the reason is due to the fact that people who are good enough to write a mobile web app that works well are simply not doing so, either because that's not what they do or because they prefer working in native technologies. Meteor+Bootstrap+Hammer+basic googling gets you head and shoulders above most people in the mobile webapp world, but that's not the status quo, despite those being some of the easiest-to-use frameworks I've ever worked with in the web space.
I suspect, but I really just don't know. shrugs
* Yes, some are as good as mobile apps, and it's not very difficult to be vastly better than the vast majority of mobile web apps, but good web app UXs remain rare birds for whatever reason
The "Doc McStuffins" game is hardly a counter-example in that it doesn't replace anything that would be considered part of the web. The argument wasn't that all mobile apps are "the web."
How many of those could honestly be called "web" in any way at all? 5%? 10%? It's a stretch to claim otherwise.
As a category, games are used a lot and non webby. That would be the main counterpoint.
That would mean Facebook, even when it uses HTML/CSS. And any other app that limits access when you're not registered. At least in Facebook's case there is a reason.
Games and many other types of apps that aren't part of the web today could be. Not in terms of running on HTML5/WebGL but their levels being indexed in search engines for example.
It's not the web (and not like the web) if I can't share or include in my own site/app a link to a piece of content from your app in a way that the creator didn't explicitly design in; a link that someone else on an entirely different platform will be able to reach without hurdles.
It's not the web (and not like the web) if I need any kind of permission from others to have my content reachable, searchable and available to everyone in the world.
The web is not a set of applications or sites. The web is in the interconnection of those applications or sites.
The advent of single page apps muddied the waters, but they still allow to share select resources easily.
Native apps are silos, full stop.
Except that they're sometimes not, and certainly don't have to be. There's no reason why HTML has to be the One True Form of hypertext - inter-app deep linking and app-to-HTML linking do exist, even if they aren't quite as widespread and cross-platform as HTML-to-HTML linking. There's nothing fundamentally different about the way HTML links than the way iOS or Android apps link to each other: it's just that one is more common and works on more things.
I still prefer HTML's linking, but I also prefer the experience of a native app (for now). There's no fundamental difference between them, beyond the issue of distribution (which is an important one, but not one you mentioned).
App-to-html linking is obvious - I'm much more interested about how html-to-app linking would (or could be made to) work.
Mobile apps are endpoints of the web.
And in doing so we're losing the extremely low barrier to entry for new apps, and we're introducing centralised controllers of what we may access.
It discourages the tinkerers and self-publishers, turns users into plain consumers, it creates gate-keepers to the new lands and reduces privacy.
I like apps, but I like openness more.
The first technical: When you search for something in Google or Bing you are being surfaced information related to your keywords. Whether that would be an article, a web app, a blog...etc When you search for an App, you are being surfaced an application to solve a certain task.
The second is behavioral: We have conditioned ourselves to use Google to find an answer to our question. In that case, Google is an app we use to find answers to our questions. We have also conditioned ourselves to use the App Store as the gateway to find a certain experience for our smartphone. The average consumer can't differentiate between a web app or a native app, they just know that in order to get an experience on their smartphones the app store is the place to do it.
2. Apps take longer to develop, require more skill & time investment, and (if iOS) have to go through byzantine approval process. This mean longer iterations, less risk taking => slower innovation
3. The higher barrier of entry keeps a lot of people of the type that made the Web interesting from creating apps. Web dev was simple enough to allow non-techies to create some pretty interesting stuff. Most apps feel like they've been created by corporate dev teams or geeky college kids.
4. There's definitely a class of apps which couldn't be implemented as web apps - but that's mostly because the OS provides a limited API to the phone's features, not some inherent weakness of the Web model.
For equivalent functionality/experience levels? That doesn't seem obvious to me.
But even if that's not the case, new devs can get started by using open source software like Wordpress etc and learn to modify it as they go. I don't know of any equivalent in the app space.
Gruber: Mobile apps and the Mobile web are the same thing because both use HTTP. And the walled garden thing isn't bad because Google and Apple compete and Bitcoin seems to be succeeding anyway.
This is quite the loaded statement & a self-fulfilling prophecy in practice. It's quite common to see a full page prompt to download the App in big letters, and tiny text to continue onto the mobile site.
Of course it's a better experience to use the app. The first experience of the mobile website is an intrusive advertisement saying "use the app".
Given an apples to apples comparison, I find that mobile apps often don't have all of the features of the website. Youtube comments is a good example. You simply cannot edit comments on the mobile app.
Native Mobile apps also fragment development effort. This leads to a worse overall platform experience, since the development is fragmented to n platforms (don't forget about Windows & Firefox phones). When new features need to be added, they need to be developed on all platforms. The more complex the feature-set & UX, the worse this issue becomes.
This fragmentation is mitigated by using a tool like PhoneGap. However, you still have added complexity via versioning. It's overcome-able.
My current project has a rich mobile web experience. We also use phonegap, so all development is in sync. The featureset is complex & rapidly evolves. There are many edge cases. It would not be a practical business with n codebases.
I don't know what Secret is, but Instagram, WhatsApp, and Vine aren't companies. They are divisions within Facebook and Twitter.
In fact, we should question why there are no big companies that have risen from the app-world that come close to the web's most successful companies: Amazon, Google, Facebook, even Yahoo.
That should tell you something that all of the app companies wind up being bought by web companies.
Every single one of those (Instagram, WhatsApp, Vine) started as startups with 1-2 employees before they were acquired by Facebook/Twitter.
I do! There is nothing to install; it will be available anywhere and work on any device, not just in the MegaCorp App Store for certain devices; it's probably more secure since there are no permission prompts that might sneak certain capabilities past you; you can publish whatever content you want without having to get prior approval; you can update whenever you like without having to wait for acceptance. Obviously there are some practical concerns (performance, features, monetisation etc), but things are getting better. E.g. on the tech side, WebGL is now available on pretty much every mobile OS except iOS (for Android, use Chrome), 'add to homescreen' gives you an app-like icon and fullscreen experience on both iOS and Android (again with Chrome), and fullscreen API support gives you an app-like experience even from the browser itself. I think in the long run that the mobile web and native apps will have approximately the same capabilities for the majority of use cases, and the key differences will only be distribution and monetisation - both of which are solvable (startup idea anyone?)
For me, the main point is the web has always been an open platform you can do what you like with. The control is all with the developer. App stores take that control away, locking your app in a vendor-specific walled garden - assuming they let you in - which they can then evict you from at any time for any reason. Surely that's not better than the web?
On the other hand, most people only use one browser with one shared cookie store, which makes it much easier to be tracked than by a set of separate apps.
Except the web browser, and a "full-featured" web browser is more complex to implement than some entire operating systems.
it's probably more secure
There is no such thing as 'probably secure.' And while after herculean effort the browser projects (which nowadays can be counted on the fingers of one hand, even if you're missing a finger or two) might be making the code more secure, the industry as a whole has been busily creating a minefield for twenty years in which users are supposed to type personal information into some sites, but not others, with no workable system to decide which sites are trustworthy. (If facebook started using self-signing keys, do you really think it would hurt usage in a more than single-digit percentage?)
you can publish whatever content you want without having to get prior approval; you can update whenever you like without having to wait for acceptance.
Also true for apps, or as they've been known in the past, "programs."
WebGL is now available on pretty much every mobile OS except iOS
and opengl is available even there, and you don't have to choose a specific browser to use it anywhere.
I think in the long run that the mobile web and native apps will have approximately the same capabilities for the majority of use cases
I agree with you, but only because native apps all embed browser cores, and are largely repackaged websites munged to work partially on-device.
For me, the main point is the web has always been an open platform you can do what you like with. The control is all with the developer.
This is a stunningly anti-user sentiment.
* App stores take that control away, locking your app in a vendor-specific walled garden*
This is another way of saying "app stores maintain quality control" -- something invaluable to people who are not web developers.
Surely that's not better than the web?
Maybe not for programmers. For users it's a godsend.
I think both agree that without native apps, we wouldn't have many of the functionality that we have today. But, there's still the real risk that any app could be removed or prohibited from the App Store for unclear reasons.
Yes, they all use HTTP/HTTPS, and yes, they often connect to the same services, with desktop versions running as web pages and mobile versions as apps. That's all true. But the IMO primary difference remains, which is that apps are controlled by two corporations while the web is not.
Saying Apple banning Bitcoin is fine, because Bitcoin will do well in other places anyway, is like saying banning freedom of speech in Turkey is fine, because freedom of speech is doing well in US.
... what?
The same way they have for ages, I suppose. These are messaging-over-IP apps with basic UIs and little to no difficult problems with regards to client performance. I sort-of-maybe-agree with most of what he says here, but it's bafflingly ridiculous statements like this mixed in with mostly accurate (if somewhat biased, just like everyone else) that make me shake my head at Gruber every time I read him.
And the original idea of the web is that the user, or the user agent, can traverse these links to move navigate the web. Without a standard document format that includes hyperlinks, I don't see how it can be called the web.
The web app evengelists (of which I am certainly one) often miss the importance of the little affordances that web apps don't have. This is both on the user and developer side, though the problem is primarily on the user's side, as developers can work around things. It is tremendously important that I be able to get instantly into my app by typing in my normal application launcher. I want to use the app without having to think about the technologies undergirding it first. It is tremendously important that I be able to silo a web app to its own window and be able to alt-tab between it and my browser. It is tremendously important that my basic shortcuts work in the app without doing strange things and occasionally killing it all together.
The problem is, this can't be achieved without large amounts of work from either the user (standard web apps with an arcane mix of desktop shortcuts or their equivalent and bizarre browser configuration), the developer (node-webkit apps like Atom or Light Table), or both (Chrome packaged apps, which manage to combine the worst of pretty much every world).
Ironically, the system on which web apps work best as part of the system, bar none (except ChromeOS because duh), is iOS, and even it has fundamental issues (no background persistence, easy to follow a link and be unable to go back to where you came from, various UI standards not working by default with the web) that make web apps, even the best of them, stand out like a sore thumb.
There's been a lot of work recently to fix this, but we're simply not to the point that web apps are anywhere in the same universe as indistinguishable from native apps. Personally, I have an optimistic view of the future in regards to the issue, but I also see Gruber's point: we web evengelists are being unrealistic when we blame the current failure of the web as an application delivery system for general-purpose applications for both desktop and mobile on some Apple's nefarious "closed garden" or other such complaints. Reality is, the web isn't there yet, and until it is, the web we have is the one we have, and we shouldn't be bemoaning the death of open standards while the whole world is speaking HTTP, just because our specific darlings aren't up to par yet.
This was slightly longer than intended. My apologies.