Live data from Hacker News

Mobile shift: You’ve probably underestimated just how big this is

trigger.io

71–80 of 123 posts

Re: Mobile shift: You’ve probably underestimated just how big this is

#71

Earlier quoted context omitted.

The "native" facebook app is just an html5 webapp believe it or not.

I believe it has both native as well as HTML5 elements, just like the LinkedIn app.

I believe at least the News Feed is HTML5.

I discovered it when I was at Starbucks. My session expired and the NewsFeed displayed the Starbucks login page instead.

Re: Mobile shift: You’ve probably underestimated just how big this is

#72
This is probably true for companies targeting casual users. Facebook and YouTube are great examples.

But I can't see people switching to mobile for the bulk of their serious, work-oriented computing unless the hardware experience drastically changes. I would never program on an iPhone or iPad if a computer were available. Nor would I want to do serious video editing, or CAD. I probably wouldn't even want to type a book on an iPad unless I had an external keyboard and mouse--and at that point, how different is it from a laptop?

Granted, most of these use cases can't be done on the web today. But that may (or may not) change. And even now, there are professional tasks that I'd much prefer to do on a laptop or desktop than on a mobile device--for example, updating Basecamp to-dos.

I also wonder whether this mobile vs web distinction will persist in the long run. Imagine a future where the most popular way to access Facebook is by clicking an icon on your iPad, which launches a Facebook mobile version in Safari or a very thin native app built around UIWebView. Is this mobile, or is this the web? At that point, I think the distinction becomes meaningless.

Re: Mobile shift: You’ve probably underestimated just how big this is

#73
As a web developer is pains me to say this, but I think that this is a good thing. The web moves so slowly; it will never keep up with native apps.

Some people are definitely concerned this leaves us in a less open world, but IMO, we'll be just fine. The most important part to have open is the data/logic layer, and that has happened through the explosion of APIs.

Re: Mobile shift: You’ve probably underestimated just how big this is

#75

Earlier quoted context omitted.

The "native" facebook app is just an html5 webapp believe it or not.

I have no trouble believing it, which is a big part of why it has such terrible ratings and reviews now, as compared to when it was native. And from what I understand, Facebook has done a lot of significant engineering to try and improve the performance while keeping it mostly HTML5. Mobile web apps aren't ready.

The FB app was heavily using webviews long before the most recent redesign. I could be wrong, but if I remember correctly it was even mostly web-based back when Joe Hewitt was still working on it, and he left Facebook in 2009.

Re: Mobile shift: You’ve probably underestimated just how big this is

#76

Earlier quoted context omitted.

I've seen the opposite. Almost everyone I know uses the native facebook app versus going to m.facebook.com. Most people only use a few websites/apps on their phones, and I think it's just simpler to tap on the app icon rather than start up mobile safari and type m.facebook.com.

Facebook is an app you use often, so the increase in responsiveness is well worth it. In the case of most startups, native apps are unnecessary. I already see that feeling trend my geek friends ("Ah, not another of those sites that want me to download their app. I just want to see the [movie listings, items for sale, opening hours, etc.]"). Worth noting, also, that Facebook (and Twitter) is mostly just a window with…

>> In the case of most startups, native apps are unnecessary.

I think the point the original post was trying to make was that in deciding between Web and native app, only native apps will be necessary. In other words, why spend the time developing a Web app when everyone will use it on a mobile anyway.

(I just want to point out that there's a large part of my soul that is just torn over agreeing with this post, because I would much prefer an open Web to proprietary apps. And I built Web apps for years. However, denial does not become an entrepreneur.)

Re: Mobile shift: You’ve probably underestimated just how big this is

#77

Earlier quoted context omitted.

The "native" facebook app is just an html5 webapp believe it or not.

I have no trouble believing it, which is a big part of why it has such terrible ratings and reviews now, as compared to when it was native. And from what I understand, Facebook has done a lot of significant engineering to try and improve the performance while keeping it mostly HTML5. Mobile web apps aren't ready.

[deleted]

Re: Mobile shift: You’ve probably underestimated just how big this is

#78
post #12

Earlier quoted context omitted.

I wonder how mobile web fits into this. Sure, native apps are great, but I'd much prefer to not need to switch between a bunch of native apps and just use my phone's web browser. Mobile web apps like Facebook prove that you can build a non-trivial app that runs in a web browser and have the experience be so good that people don't even care about the native app version (at least everyone I know just uses Facebook righ…

I think you might want to question your assumptions. The reason you want to do everything in the browser is probably twofold: 1) Inertia (that's the way I've been doing it for a decade, dagnammit), and 2) It's an easier context-switch. Rather than go back to the home screen, swipe over to the next app, and tap it, you just just type in the first few letters of the url, then select the site you want to go to from the…

It's not inertia, but it is an easier context-switch, IMO.

If you made an "app browser" that allowed better searching (type the first letter and the app appears --- tap to open it), sorting (like bookmark folders) and easy navigation between apps, you'd be presenting me a much better experience than the current process of finding and switching between apps on your phone.

That said, I still think pure mobile web could be the future. Why couldn't Apple allow mobile web apps to be sold in the app store? It's an icon that opens a web page. It could be as simple as that.

Let's take it a step further. Imagine that when you download this new type of mobile web app, Apple calls a JavaScript API that reads the HTML manifest in the 'index' file and loads the resources in the background. Apple shows the downloading bar over the app icon while this happens, just like downloading an app today. When you click it, everything is loaded and ready to rock.

Re: Mobile shift: You’ve probably underestimated just how big this is

#79
I just had another thought on this: mobile usage does not necessarily imply that the back-end is entirely on the device as well.

For example, the app I'm building right now has an entirely iOS-based UI, but the brains are hosted on the public Web via API. The app talks to the back-end via Websockets for anything that requires brains.

This type of architecture allows your application to participate in the UI-du-jour (native apps) while at the same time participating in the open Web. And you can simply write another client when another type of device (I dunno, Kinect?) becomes the consumer's preferred method of consuming. I think it will become much more popular in the coming years.

Re: Mobile shift: You’ve probably underestimated just how big this is

#80
post #3

I find this trend disturbing. This is essentially the opposite of what happened in the 90s during the mass migration from curated networking experiences like AOL and CompuServe towards the unfettered Internet. Now, people are willingly eschewing the open web in favor of, in the case of iOS, walled gardens. And unless this is reversed, it portends a dismal future for the Internet.

Javascript had already started killing the web. The industry is going to regress to client/server, and whether the platform will be browsers or mobile devices' own window systems is just an implementation detail. The tradeoffs differ, but they both suck compared to addressable content in standardized formats.
Post reply on HN