It's All Software(daringfireball.net)
daringfireball.net
It's All Software
http://daringfireball.net/2011/06/its_all_software
73 comments
Hubris in what way?
I think back there's a common belief in nerddom that it's gotta cover all these technical topics or else it's bad. Most people that use iCloud will not care about anything else other than the fact that their data 'magically' appears where it's needed. This is where I completely agree with Apple and diverge from the tech crowd - the best experience should just work.
I think back there's a common belief in nerddom that it's gotta cover all these technical topics or else it's bad. Most people that use iCloud will not care about anything else other than the fact that their data 'magically' appears where it's needed. This is where I completely agree with Apple and diverge from the tech crowd - the best experience should just work.
Will it magically appear on my linux box?
Does that matter? Linux has a rather low market share, especially among Apple’s target demographic.
Gruber: ... Apple’s vision for “access anywhere” is “iPhone everywhere”.
The problem is that the dream of iPhone everywhere is dead for most people. Android isn't looking back. iPhone will never surpass Android in marketshare again. For most people, if the iCloud means an iPhone device, that means iCloud won't be used.
The problem is that the dream of iPhone everywhere is dead for most people. Android isn't looking back. iPhone will never surpass Android in marketshare again. For most people, if the iCloud means an iPhone device, that means iCloud won't be used.
Hm, how is “iPhone everywhere” meant, though? I read it as “my iPhone with me everywhere”, not as “everyone has an iPhone”. You might be talking about two different things
Yeah, you're definitely right. Although the lack of ubiquity is still a problem -- especially if iOS devices stay flat in terms of marketshare. iOS owners will have to tether everything into their iPhone. People with the other clouds will have first class support of their cloud data with whatever device they use.
Yeah, those two things are not entirely unrelated. Making having an iPhone with you everywhere really useful will also depend to some extent on how good you can collaborate and share with other people.
You shouldn’t forget that connection but I also wouldn’t exaggerate it. Also, iOS still has a sizable market share, maybe more than the Mac ever had? That helps, too.
You shouldn’t forget that connection but I also wouldn’t exaggerate it. Also, iOS still has a sizable market share, maybe more than the Mac ever had? That helps, too.
Some of Apple's new stuff sounds very much like they are going with everyone has an iPhone. Facetime, iMessage etc
>For most people,
There are circles within circles though... and I think that's what Apple is marketing to.
There are circles within circles though... and I think that's what Apple is marketing to.
Maybe, maybe not. But so what? Apple has never been about mass market (perhaps excepting the iPod). If you want the best possible experience and "it just works" and you can afford it you will get the iPhone. That niche may not be the largest but so far it has been the most profitable.
Market share is the runner-up prize for those who value a large community of vocal spendthrifts.
People aspire to an iPhone, they settle for Android.
Market share is the runner-up prize for those who value a large community of vocal spendthrifts.
People aspire to an iPhone, they settle for Android.
Good point. He left out the "mac only" aspect of the discussion. I have a Macbook and an Android phone and an iPad but iCloud doesn't change the way I use any of them because I'm not using an iPhone.
This is Gruber at his best. He correctly points out that the distinction people (including me) seem to be drawing is basically an arbitrary one.
I think the more abstract distinction comes from what each company wants you to do with their products, though. Apple wants you to use their hardware. What you use it for doesn't matter so much as you using it, and every decision they make, including leveraging the cloud, is informed by this.
Google, on the other hand, wants you to use the web, because the web is where they get paid. And the web is where we connect to each other.
Google's model makes that connection its fundamental primary motivation, while for Apple, the connection is incidental, just another feature.
I think the more abstract distinction comes from what each company wants you to do with their products, though. Apple wants you to use their hardware. What you use it for doesn't matter so much as you using it, and every decision they make, including leveraging the cloud, is informed by this.
Google, on the other hand, wants you to use the web, because the web is where they get paid. And the web is where we connect to each other.
Google's model makes that connection its fundamental primary motivation, while for Apple, the connection is incidental, just another feature.
Apple wants you to use their hardware. What you use it for doesn't matter so much as you using it
This is unfortunately less true than it used to be. It matters to Apple if you want to run unapproved software on an iPad, or heaven forbid install Linux on it. I expect these restrictions will be coming to Macs over the next few years.
Google, on the other hand, wants you to use the web
Google wants you to use Google services and see ads that make Google money. They don't especially care whether that means web apps with AdSense ads or native apps with AdMob.
This is unfortunately less true than it used to be. It matters to Apple if you want to run unapproved software on an iPad, or heaven forbid install Linux on it. I expect these restrictions will be coming to Macs over the next few years.
Google, on the other hand, wants you to use the web
Google wants you to use Google services and see ads that make Google money. They don't especially care whether that means web apps with AdSense ads or native apps with AdMob.
It matters to Apple if you want to run unapproved software on an iPad, or heaven forbid install Linux on it.
Doesn't it make more sense that Apple is trying to build a large and consumer friendly platform (approved apps) and that it would be an unjustifiable expense to support installing alternative OSes (Linux)?
Why is there always the assumption of nefarious motivations when it's more simply explained? They are only trying to make money, after all.
Doesn't it make more sense that Apple is trying to build a large and consumer friendly platform (approved apps) and that it would be an unjustifiable expense to support installing alternative OSes (Linux)?
Why is there always the assumption of nefarious motivations when it's more simply explained? They are only trying to make money, after all.
"I expect these restrictions will be coming to Macs over the next few years."
Considering the influx of open-source hackers and ex-windows users that migrated to Mac after the switch to Intel, this is just... nuts.
Or maybe just FUD.
Considering the influx of open-source hackers and ex-windows users that migrated to Mac after the switch to Intel, this is just... nuts.
Or maybe just FUD.
> I expect these restrictions will be coming to Macs over the next few years.
I doubt it - iOS has only got less restrictive over time (From no 3rd party apps, to 3rd party apps in Objective-C, C++ and C, to 3rd party apps in any language)... Why would they would go in the opposite direction on the Mac and alienate all their current Mac users?
I doubt it - iOS has only got less restrictive over time (From no 3rd party apps, to 3rd party apps in Objective-C, C++ and C, to 3rd party apps in any language)... Why would they would go in the opposite direction on the Mac and alienate all their current Mac users?
Apple makes their money from hardware sales, so their services will be locked or closely tied to their devices. While Gruber may be right with Apple bringing a web interface to some of iCloud, it won't be their focus. And that makes perfect business sense.
Google, on the other hand, just wants to serve you ads. That could be on HP, Dell, Apple, or Samsung hardware (although, I'm sure they'd prefer you bought Android or Chrome devices).
Personally, I prefer to buy Apple devices and use Google services. Apple makes the best hardware, but I don't want to be forced into buying them forever. With Google I can be assured access to my data from just about any future hardware vendor.
Google, on the other hand, just wants to serve you ads. That could be on HP, Dell, Apple, or Samsung hardware (although, I'm sure they'd prefer you bought Android or Chrome devices).
Personally, I prefer to buy Apple devices and use Google services. Apple makes the best hardware, but I don't want to be forced into buying them forever. With Google I can be assured access to my data from just about any future hardware vendor.
Why do you prefer to lock your data to a service provider rather than a hardware provider? You are still choosing something to hitch your wagon to.
The service provider has a reason to make it easy to use their services on any hardware. Hardware provider has a strong reason to not make it easier to access their services from third party hardware. So why not go with the company that doesn't care* how you access them, especially in the context of your data? It is repeat of why Kindle is much more successful than iBooks.
*Google is blurring the line a bit with Android, but still makes their real money from their services.
*Google is blurring the line a bit with Android, but still makes their real money from their services.
I think you are spot on describing one side, but it's worth looking at the other side. How do these companies make money? For the hardware company, that's easy. For the service company, that's monetizing your data. Apple cares more about how you access data, but less about the data itself. For Google, they don't care how you access your data so long as their algorithms also have access.
The Kindle example veers off slightly from Google because people pay for their ebooks.
The Kindle example veers off slightly from Google because people pay for their ebooks.
Im much more comfortable if the company Im paying makes money on the hardware I buy and doesn't make money on my data.
What makes you think Apple won't make money on both?
With iCloud Apple will potentially make money off the service because some customers will pay cash for extras (more space, more services, etc), but that's it.
Apple is a weird company because for all the eyebrows they raise with talk of closed systems and hubris and whatever else, they primarily make their way in the world by selling goods to consumers for money. The infrastructure enabling that is a crazy thing, but the heart of it is pretty old fashioned.
Apple is a weird company because for all the eyebrows they raise with talk of closed systems and hubris and whatever else, they primarily make their way in the world by selling goods to consumers for money. The infrastructure enabling that is a crazy thing, but the heart of it is pretty old fashioned.
At the Keynote Stece Jobs had a bulletpoint "no Ads". I like that.
I do think my data is safe and private at Google (not so much trust in Yahoo and Facebook), but I am certainly looking forward to iCloud. Example: Gmail is a really good and free email-provider, but it also really sucks if you go through times that suck like a break-up and the adsense advertising is mirroring the unpleasant mails stored in your inbox.
I do think my data is safe and private at Google (not so much trust in Yahoo and Facebook), but I am certainly looking forward to iCloud. Example: Gmail is a really good and free email-provider, but it also really sucks if you go through times that suck like a break-up and the adsense advertising is mirroring the unpleasant mails stored in your inbox.
Exactly
If you aren't paying for the product you are the product.
If you aren't paying for the product you are the product.
Exactly. I've bought many kindle books but have no interest at all in buying through iBooks. I do have several Apple devices now but I don't want to be chained to them forever.
Google also makes it fairly easy to export all your data if you decide you want to pick up and move.
Google also makes it fairly easy to export all your data if you decide you want to pick up and move.
Exactly what bits of iCloud will be hard to export? Music? All DRM-free now. Photos? Sync to your Mac/PC and copy anywhere? Mail? IMAP. Calendar? Caldav. Documents? Sync to your Mac/PC again…
Bingo, thanks for saying it better than I could. The Kindle ecosystem is a perfect example.
Apple solved this with the App Store, though — local native software with truly simple, obvious, easy installation and complete encapsulation of data.
The app store certainly makes it easy but its no where close to the easy installation and update of webapps - typing a name and hitting enter or clicking a link.
Wouldn't it be more appropriate to say that Apple's vision of the cloud is "data in the cloud. apps are local" whereas Google's vision of the cloud is "data and apps are in the cloud"?
All of Google's client-side software also comes down from the cloud the same way your data does.
The app store certainly makes it easy but its no where close to the easy installation and update of webapps - typing a name and hitting enter or clicking a link.
Wouldn't it be more appropriate to say that Apple's vision of the cloud is "data in the cloud. apps are local" whereas Google's vision of the cloud is "data and apps are in the cloud"?
All of Google's client-side software also comes down from the cloud the same way your data does.
We'll have to agree to disagree. URL discovery is still a major problem, it's what made Yahoo as a human-curated index popular back in the 90s. In my admittedly anecdotal experience with seniors, many of them still have difficulty understanding the browser since they are task-oriented, rather than URL-oriented. And apps are task-oriented. URL bookmarks saved to the home screen help but are still prone to problems e.g. website alters the landing page and now the browser returns a 404. No problem for us but a very jarring experience for seniors who don't know URI.
And Gruber's point is that web apps still require internet access to work, albeit with improvements like cached storage in HTML 5. Whereas apps on the mobile device already work and are already taking advantage of sensors onboard the device, but the internet (cloud) makes them even better. For example, Garageband for iOS would be really hard to do as a webapp. Not impossible, but hard.
And Gruber's point is that web apps still require internet access to work, albeit with improvements like cached storage in HTML 5. Whereas apps on the mobile device already work and are already taking advantage of sensors onboard the device, but the internet (cloud) makes them even better. For example, Garageband for iOS would be really hard to do as a webapp. Not impossible, but hard.
"URL discovery is still a major problem"
come on, google search is smarter than the app store search
come on, google search is smarter than the app store search
I made no mention comparing the quality of search results because that's a whole other topic.
I'm saying the App Store has categories, "Staff Picks", "iPad App of the Week" etc and it helps in discovery, just like Yahoo did back in the day.
Google would have to tread carefully here or they would step on advertisers' toes or invite anti-competitive scrutiny due to their dominance in search.
I'm saying the App Store has categories, "Staff Picks", "iPad App of the Week" etc and it helps in discovery, just like Yahoo did back in the day.
Google would have to tread carefully here or they would step on advertisers' toes or invite anti-competitive scrutiny due to their dominance in search.
Google doesn't have to do this, web takes care of recommendations. We have HN, Reddit, StumbleUpon, etc.
All those things benefit both web apps and native apps.
Google Web Store might help.
"its no where close to the easy installation"
I'd beg to differ. It may not be identical, but App installation on my iPhone/iPad/Macintosh from the App Store is pretty much "Click, authorize, done"
I'd beg to differ. It may not be identical, but App installation on my iPhone/iPad/Macintosh from the App Store is pretty much "Click, authorize, done"
On a web app, installation and updates are basically 'open the app'.
I'm not saying the iOS process isn't dead simple - it is - but its still a step behind web apps.
I'm not saying the iOS process isn't dead simple - it is - but its still a step behind web apps.
Lets just presume the web is simpler than app store installation, does that difference actually matter? I'd say it doesn't. As soon as you've reached a certain level of easy becoming easier doesn't give you as much gain. The advantages of native applications certainly outweigh the tiny extra work on installation.
App store installation does have one other advantage: a sense of ownership. The user feels they own the app rather than merely visiting it -- psychologically that is a powerful difference.
App store installation does have one other advantage: a sense of ownership. The user feels they own the app rather than merely visiting it -- psychologically that is a powerful difference.
This can be fixed, but the fact that iOS and Android don't have a "automatically update in the background without telling me" is insane to me. I go weeks without going into the App Store on my iPad and when I do there are usually 4 or 5 updates waiting. They could easily update in the background -- why don't they if I've given them permission?
Automatic updates is one of the features of iOS5. So, its coming
With a webapp, the "installation" step is usually replaced with a "register" step. So in effect "install" becomes "enter desired username and password", "check for confirmation email", "click confirmation link", "log in".
That's a little 2005ish. Today we have a couple of ways to ease this:
1) With local storage registration isn't necessary in a lot of cases. It is only needed so the user can have the same data on multiple computers.
2) We have Facebook Connect, Google Login, Twitter Anywhere, etc today. It's a 2 step process, "Login", and "Authorize".
1) With local storage registration isn't necessary in a lot of cases. It is only needed so the user can have the same data on multiple computers.
2) We have Facebook Connect, Google Login, Twitter Anywhere, etc today. It's a 2 step process, "Login", and "Authorize".
I'm a little tired of the notion that UX == UI == UX. It doesn't. Native apps clearly have the advantage on UI --- for now --- but on UX it's a lot closer. Part of UX is being able to sit down on my Linux desktop and not have to worry about whether I can check my calendar. Part of UX is not having to exit out of what I'm doing to simple check the weather. Part of it is not having to choose which computer I buy based on whether it is compatible with the document format I use. These are just a few of the areas where web aps have a strong lead in UX (and I'd add "installation" in there as well).
I'd argue that the reason I can keep using Linux is knowing there's good (or good enough) stuff out there for me to use, the only requirement being that I have a modern browser and an Internet connection. There's less and less reliance on some group of people deciding to clone some existing project or create something from scratch -- boy, do I remember the days of diving deep into freshmeat.net just to find something that would open PDFs and not suck.
The UX thing is why I'm slowly warming up to the Chromebook idea. I own an iPhone, and I love Macs, but I think ultimately the constraints of native applications will work against the users. We should cherish the million frameworks showing up instead of raising the "too much choice" flag just yet, as they will (hopefully) yield a development experience as enjoyable as the current tools for iOS, Android and Windows Phone seem to.
The UX thing is why I'm slowly warming up to the Chromebook idea. I own an iPhone, and I love Macs, but I think ultimately the constraints of native applications will work against the users. We should cherish the million frameworks showing up instead of raising the "too much choice" flag just yet, as they will (hopefully) yield a development experience as enjoyable as the current tools for iOS, Android and Windows Phone seem to.
I don't think there is a correlation between quality user experience and desktop software. He breaks down the difference between desktop and web-based software only to falsely associate one with user experience and one with mass-adoption.
I think choosing between the two depends on what type of app you plan on making, the type of users you target, business goals and a ton of other options.
I love how he's correctly reframed the native vs web discussion but am disappointed he decided to make it a war again. It's not a holy issue: choose what's best for your business.
I think choosing between the two depends on what type of app you plan on making, the type of users you target, business goals and a ton of other options.
I love how he's correctly reframed the native vs web discussion but am disappointed he decided to make it a war again. It's not a holy issue: choose what's best for your business.
Latency and responsiveness are still a huge problem for web apps, especially on mobile devices. Elements consistently come into view only when they're ready, jerkily appearing out of nowhere, as opposed to in native designed interfaces in which everything is presented instantaneously. UI feedback is often delayed, inappropriate, or at times nonexistent. This is pretty consistent across the board.
As for the user experience argument, I'm still looking for a valid excuse why the Facebook mobile website is so astronomically poorer in all aspects to the Facebook for iPhone app. In theory, they can and should function exactly the same when viewed on such a device, but they are leaps and bounds apart.
As for the user experience argument, I'm still looking for a valid excuse why the Facebook mobile website is so astronomically poorer in all aspects to the Facebook for iPhone app. In theory, they can and should function exactly the same when viewed on such a device, but they are leaps and bounds apart.
Latency is still a huge problem for web apps, especially on mobile devices. Elements consistently come into view only when they're ready, jerkily appearing out of nowhere, as opposed to in native designed interfaces in which everything is presented instantaneously. This is pretty consistent across the board.
Ironically this is almost the polar opposite of Gruber's view. Gruber argues in this piece that web apps are local client apps running on your mobile device (and he urges you to view source). Both forms of apps (native and web apps) can mask latency in the same ways.
Ironically this is almost the polar opposite of Gruber's view. Gruber argues in this piece that web apps are local client apps running on your mobile device (and he urges you to view source). Both forms of apps (native and web apps) can mask latency in the same ways.
Latency and responsiveness are still a huge problem for all network-heavy apps.
We have a professionally used iOS app that relies on server data (the magical cloud) and the number one user complaint is speed. Creating your client on iOS rather than in HTML/JS doesn't give you any magical "Latency and responsiveness" user experience unicorns.
We have a professionally used iOS app that relies on server data (the magical cloud) and the number one user complaint is speed. Creating your client on iOS rather than in HTML/JS doesn't give you any magical "Latency and responsiveness" user experience unicorns.
Distributed software will work perfectly, provided it works under perfect conditions :)
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...
Oh but it's real and people are choosing Reeder over Google reader, people are choosing mail.ipa (or Android equivalent) over Gmail web interface. With good API, people will choose native Google Docs apps too.
Cloud is the service is the soul and is the only truth, but it also works best invisibly.
Cloud is the service is the soul and is the only truth, but it also works best invisibly.
Topolsky: "There is no native application for the Mac or iOS that replicates the shared document editing of Google Docs;"
Gruber: "The first clause isn’t true, I’d argue. Shared document editing is not an inherent advantage of Google Docs being web-based; a native client could do it just the same."
Well, sure it could (subethaedit demonstrated that well) but Topolsky clearly stated that no native apps exist that allow it right now. Great, a native app could. Whoopee. No one's doing it yet. :/
Gruber: "The first clause isn’t true, I’d argue. Shared document editing is not an inherent advantage of Google Docs being web-based; a native client could do it just the same."
Well, sure it could (subethaedit demonstrated that well) but Topolsky clearly stated that no native apps exist that allow it right now. Great, a native app could. Whoopee. No one's doing it yet. :/
Apple's proprietary web.
It's true the distinction between networked native apps and networked browser apps is logically arbitrary; but the practical distinction is that the web is an open standard, cross platform, widely adopted, whereas Apple's native apps are tightly integrated with the device, giving them faster response and a better managed user experience. If iOS is everywhere, then you get the best of both worlds.
Can Apple topple the web? If they are better at providing what users want, yes.
It's true the distinction between networked native apps and networked browser apps is logically arbitrary; but the practical distinction is that the web is an open standard, cross platform, widely adopted, whereas Apple's native apps are tightly integrated with the device, giving them faster response and a better managed user experience. If iOS is everywhere, then you get the best of both worlds.
Can Apple topple the web? If they are better at providing what users want, yes.
"Can Apple topple the web?"
well, then assuming a web page === a web "app"
the number of websites available to users is probably one million times the number of apps...
the number of new web sites that are started each day is probably one thousand times the number of new apps....
apple has a ways to go
and yes, i'll go there...you can't "kill" the real web if you do not allow users to access copious amounts of hardcore pornography
well, then assuming a web page === a web "app"
the number of websites available to users is probably one million times the number of apps...
the number of new web sites that are started each day is probably one thousand times the number of new apps....
apple has a ways to go
and yes, i'll go there...you can't "kill" the real web if you do not allow users to access copious amounts of hardcore pornography
I'm not so sure Google's long term strategy is to bet it all on browser based clients and reach at the expense of user experience. They have NativeClient in ChromeOS, which may be a play to write a more traditional OS but better merged with the web.
The current state of the web is such a crappy experience for regular consumers that Apple's model could make some headway against it and Google wouldn't want to be moving at the pace of standards against them.
The current state of the web is such a crappy experience for regular consumers that Apple's model could make some headway against it and Google wouldn't want to be moving at the pace of standards against them.
Agreed. I think they're both fighting at both fronts, when you consider how Android embraced the app model and even expanded it (widgets etc), and how Apple was the most vocal of the HTML5 advocates...
NativeClient is a cool technology, from a pure, geeky POV. Maybe awesome stuff will be done with it, to the point of steering other browsers in its direction, but right now it's a case of having a "Designed for Google Chrome" badge on you front page or developing two code bases, one with JavaScript, another with C++, just to have the same reach you would without it -- only to end up with a crappy user experience for a lot of people.
The only way I see of furthering NaCl's agenda is if Adobe, Autodesk or some other company with a little cash to burn decides to write one of their apps (say, a Photoshop Express, or maybe a Sketchbook Pro) with it and prove in the market that there's a future in that approach. Otherwise, it will forever be just a cool hack.
The only way I see of furthering NaCl's agenda is if Adobe, Autodesk or some other company with a little cash to burn decides to write one of their apps (say, a Photoshop Express, or maybe a Sketchbook Pro) with it and prove in the market that there's a future in that approach. Otherwise, it will forever be just a cool hack.
Topolsky: ...there’s no mail application that exists for the Mac which will allow me to access my important information from anywhere in the world with or without a device in hand.
Yes there is, and I can't believe Gruber missed this. I use the iOS mail client to access my GMail account. That's the point of Gruber's argument, that GMail is a service and can have multiple client apps of which the browser app is just one.
Yes there is, and I can't believe Gruber missed this. I use the iOS mail client to access my GMail account. That's the point of Gruber's argument, that GMail is a service and can have multiple client apps of which the browser app is just one.
99% of my use of GMail is via either Apple's Mail client or the Android client on my phone. I am probably in the minority for the former, but I'm very much in the majority for the latter!
The Gmail example doesn't prove the point so well: there's a Javascript-free, widely used web interface to it that doesn't deserve to be called a client.
Something like Google Maps, or Topolsky's example of Google Docs, supports the point well enough.
Something like Google Maps, or Topolsky's example of Google Docs, supports the point well enough.
True cloud computing is when we have nothing but a display device that simply follows instructions on how to display the GUI that it receives from the cloud. The browser is a simulation of this future device.
Installing an app on a device is still the old way of doing things. All aspects of the application should come from the network - including the UI.
Why? Because then we can focus more on the nature of HCI itself instead of focusing on developing for different devices like we do now. Developers should be developing for screen sizes - not devices.
IMHO it's inevitable that we will all use one global standard for the client UI in the future. The web is the beginning of that and it's a powerful concept.
And let's not forget that every single one of Apple's iDevices will have Safari installed.
Installing an app on a device is still the old way of doing things. All aspects of the application should come from the network - including the UI.
Why? Because then we can focus more on the nature of HCI itself instead of focusing on developing for different devices like we do now. Developers should be developing for screen sizes - not devices.
IMHO it's inevitable that we will all use one global standard for the client UI in the future. The web is the beginning of that and it's a powerful concept.
And let's not forget that every single one of Apple's iDevices will have Safari installed.
This argument is nullified by the fact that computing power continues to fall in cost, size and power usage.
The user does not and should not care about where his or her application logic is being run so long as this device is affordable.
The vision you present adds questionable cost savings and substantial latency: (NY->SF->NY)/c will always take 32ms, best case. Taking this trip asynchronously instead will make sense for a very long time.
Apple understands that shuffling data between devices is a real burden to users, so they've attacked that problem instead of chasing an esoteric one.
The user does not and should not care about where his or her application logic is being run so long as this device is affordable.
The vision you present adds questionable cost savings and substantial latency: (NY->SF->NY)/c will always take 32ms, best case. Taking this trip asynchronously instead will make sense for a very long time.
Apple understands that shuffling data between devices is a real burden to users, so they've attacked that problem instead of chasing an esoteric one.
Very astute. Gruber gets it.
You mean the same way some people just 'get' Jesus?
He strikes me as a serious devotee first, analyst second.
He strikes me as a serious devotee first, analyst second.
Did you even read the article? He was quite obvious and unbiased (except - DUH - on the part where he said "I’m biased"), by acknowledging that both strategies have pros/cons.
Jesus (to quote you), people like you are worse than fanboys.
Jesus (to quote you), people like you are worse than fanboys.
[deleted](1)
[deleted]
but most stuff i access is content...and the web is great for content
i mean....does anyone actually install pointless web-in-a-box apps like the rotten tomatoes app (for example because it bugs the hell out of me to decline it each time)?
my dsire to consume content is not going away, and having an app-per-url is a nonstarter
i mean....does anyone actually install pointless web-in-a-box apps like the rotten tomatoes app (for example because it bugs the hell out of me to decline it each time)?
my dsire to consume content is not going away, and having an app-per-url is a nonstarter
I'm reminded of how Jean-Louis Gassée, head of Apple's Macintosh development in the late 1980s, responded when asked how they plan to connect Macs to the network. He held up a piece of phone wire and said "this is our network". This was a reference to Apple's proprietary LocalTalk protocol which could be used over regular RJ11 connectors.
The gist of this story is that Apple completely ignored the need for interoperability with the Mac. The iCloud has a whiff of the same hubris.