Facebook iOS App Ditching HTML5 For ObjectiveC 240
Wrath0fb0b writes "The New York Times reports that Facebook is overhauling their iOS App to ditch their HTML5 based UI for a native ObjectiveC one. This is an about face from their position a few months ago in which FB said HTML5 would allow them to write once run anywhere. While WORA certainly has a lot of appeal for both programmers (due to desire not to duplicate effort) and management alike (due to desire not to pay programmers to duplicate effort), the large number of negative reviews that FB for iOS has illustrate that this approach is not without drawbacks. No matter how the new app is received, this is more fuel on the native vs. web-app fire."
Ask any grey beard. (Score:4, Insightful)
Native code is _always_ better.
Re:Ask any grey beard. (Score:5, Insightful)
Re:Ask any grey beard. (Score:5, Insightful)
Better, in the sense that cost considerations aside, technically, it is superior almost every time.
In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice? ..and even then there's performance tradeoffs.
Write it all in assembly and get off my lawn. :)
They need to share a language (Score:3)
In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice?
I agree in principle [pineight.com]. However, sharing components among versions of an application for different platforms works only if all the platforms can run programs written in the same language, and in practice, there are a lot of platform pairs that lack a shared language. For example, how do you share a component between an application for Windows Phone 7, which runs only C# and other languages that compile to verifiably type-safe CIL and do not use the DLR, and the corresponding component for iOS, which runs Obj
Re: (Score:3)
It's called web services, that return a standard format like JSON, or XML. That's how we do it at my work. Currently I'm working on a project where I serialize perl hashes and arrays into XML, and pass them via a REST based web service to a C# system that serializes it into a DataTable for display in some .NET controls. C# can deserialize the DataTables back into XML, post it to the REST based web service to where it gets re-serialized into hashes and arrays for various CRUD type actions.
Re: (Score:2)
Better, in the sense that cost considerations aside...
Yep, that one's usually waaay down the list ;)
Write it all in assembly and get off my lawn. :)
Now, real programmers... [xkcd.com]
Re: (Score:3)
Write it all in assembly, and more likely than not for a large system you get http://en.wikipedia.org/wiki/Therac-25 [wikipedia.org]
Ask any game developer (Score:2, Insightful)
Re:Ask any grey beard. Native code is _always_ better.
Ask any game developer, well those working on anything beyond the simple casual game segment.
Android Native Development Kit (Score:4, Informative)
Ask any Mobile Developer, simultaneously writing for iOS and Android.
The need for the Android NDK (Native Development Kit) answered that question. Java-like approaches are fine for certain classes of apps but for many classes native is better.
Re: (Score:3)
And allows code sharing. The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to. Pretty much all cross platform phone apps are C++ backends with a thin GUI layer in whatever that platform is pushing.
WP7 only runs CIL (Score:2)
The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to.
I agree, so long as an application is limited to Windows, Mac OS X, X11/Linux, Android, and iOS. So what's the best practice to introduce Windows Phone 7 into that mix? It only runs C# and other type-safe managed languages that don't use the DLR. C++/CLI doesn't count because any nontrivial C++/CLI code that will compile with /clr:safe is a syntax error in a compiler for Standard C++.
Re:The Thin GUI Line (Score:5, Insightful)
If 50% of your modules have GUI calls, you're developing your software wrong. MVC isn't just for webpages. If you have UI specific code in your business logic, you fail.
If the GUI code is more than a tiny fraction of your overall code, you're working on absolutely trivial software. I can't say I've ever worked on a GUI app where the GUI itself was more than 5-10% of the code.
Basically, there's two ways of writing cross-platform apps:
1)Write your main business logic as a library. Then for each platform, write code that runs the UI and calls it as appropriate
Pros: Can take advantage of all the features of the OS, and make a customized experience for it. Easy to fit in with design standards for the OS. Minimizes bugs due to differences in APIs and capabilities between platforms.
Cons: May not be possible to write the buisness logic in this way, or may not be easy. May require ugliness in the business logic to do so. May be hard to maintain the line of abstraction between the two halves, depending on how the platform is implemented.
2)Abstract away the UI and OS specific calls into a library, and implement them for each OS.
Pros: Easy to do, with a little bit of discipline. It's always possible to do it this way, and *if* you can implement each API call so they act identically on all platforms then maintenance is a breeze and no ugliness in the business logic.
Cons: Subtle differences between how platforms handle common APIs can cause bugs. Differences between how they handle less common APIs can cause major issues. Cannot take advantage of advanced OS specific features, may not be able to follow UI standards for each platform. You'll end up with features not working on some platforms if they don't provide a needed API.
It's probably about a 50/50 split between the two paths (and I won't suggest a path, it really depends on your code and target platforms). But this is how it's done. And in either case, in fact in ALL well designed software the GUI is far separated from the business code.
Re:UI and OS abstraction library (Score:5, Interesting)
Nope, I'm going to stick by my original statement. In 11 years of professional development, the majority of which had a GUI in some shape or form- 10% is the highest I've ever seen, the average is probably on the order of 3-5%. GUIs just aren't that hard to write and don't really do that much.
Using a 3rd party library can work as well- if your platform supports the toolkit you want to use, and supports it well. Swing last I checked was a nightmare that never worked the same on any two platforms. I'm going to assume it's been fixed, as it's been years since I've used it, but trust me, it was shit. Tk looks like shit on all platforms, it's an ugly UI. It's good for a quick one off, but you'll never see it in professional software.
Then there's the question of what OSes you target. If you ever want to target a proprietary hardware OS, all of those get thrown out. They won't work, and porting them would take more time than rewriting by orders of magnitude. Nor would an OEM selling your stuff ever want to bloat the ROM with a whole QT library. And don't forget, until about a year ago the phone market was dominated by proprietary OSes, until Android came.
Then there are the smartphone OSes- Android, iOS. They don't support any of those. So once again, you're back to not using them.
And in the end, that's why you don't use them- because they aren't truly universal. Because you can't count on them being available on the next port. And the tiny cost to encapsulate the small amount of functionality you actually need is well spent to have the flexibility to say yes when an opportunity to port to a device for a few million comes up.
Now if you're only porting to Windows, Mac, and Linux you're probably good with one of those libraries. Which are all those 3 run on.
Re:Javascript vs. Jquery (Score:3)
You should write (or recommend) a tutorial called "JavaScript for Jquery developers" which shows the standard cross-platform-compatible JavaScript equivalent to the major JQuery functions.
Re: (Score:3)
Wow, that's lazy. So I guess you didn't have anything specifically in mind then?
Let's start with the biggest one: selectors. Hey, that was the whole reason jquery was written, right? .querySelector and .querySelectorAll work in all major browsers and has had broad support for years.
The most common case I see jquery abused is selecting elements by class name. Of course, most of the time it's used instead of a more appropriate solution, still, it's a popular use. .getElementsByClassName() has been around,
Re: (Score:3)
In jquery, if I wanted to do something with each element with a particular tag contained inside another dom element, I'd do something like this:
Or perhaps like this:
In bare javascript I'd have to write a loop, either recursively or iteratively.
Anyway, I don't see javascript libraries going away anytime soon. Bloated? Maybe. Useless? Depends on your point of view. If you're really dedicated to luring pr
GL on PS3/360/WP7 (Score:2)
The only non-portable parts of the engine I work on are a few lines of startup code related to the fact that Windows makes modern OpenGL harder to use than most other platforms do.
Do the game consoles and Windows Phone 7 support OpenGL? I thought Xbox 360 and Windows Phone 7 used DirectX, and PS3 used something way off in left field because the OpenGL ES implementation that ships with the devkit isn't worth an expletive. Or is your game PC-only?
Re: (Score:3)
Yeah that's true. But the iOS Facebook app is an exception, it's really just a frontend for an HTML5 site and it's super-buggy, slow and annoying. So I'm glad they are rewriting it.
Re:Ask any grey beard. (Score:4, Funny)
Re:Ask any grey beard. (Score:4, Funny)
If you can do that I'll be impressed.
Re:Ask any grey beard. (Score:5, Funny)
Re: (Score:2)
I'll happily do my part to produce orphans.
Re:Ask any grey beard. (Score:5, Funny)
I think you mean bastards. If you really want to do your part to produce orphans ...
Re: (Score:2)
I don't know. By my reckoning he's got 17 really great years ahead of him.
Re: (Score:2)
I'll happily do my part to produce orphans.
I hope you've already managed to accomplish most of what you want in life, then.
Re: (Score:2)
I hate all the orphans in the world!
Re: (Score:2)
Re: (Score:3)
And while we're on the subject, get off my lawn!
Re: (Score:2)
Not if you don't own that device.
Re: (Score:2)
The only thing true about this statement is that is will _always_ resolve to be "False". Or 0 for you grey beards.
Re: (Score:2)
Re: (Score:2)
in mobiles, since 2003 or so there has been certain developer marketing folk pushing for all-html/js solutions as the magic bullet that will make development cheaper by not having to need experts(who know what the device can do and how) and that it's just a matter of mapping javascript api's.
so after that mobile developers have been constantly bombarded with propaganda that in 1-2 years there's going to be so good js engines and renderers that it'll as good as native. an example about this is nokias web run
Re: (Score:2)
Re:Ask any grey beard. (Score:4, Insightful)
Speaking as a greybeard (both literally and as a thirty-year veteran of this industry), bullshit. When I was young there were still a few people around who could write software by writing opcodes out in pencil on the train home and have them work first time without bugs (Chris Burton, who helped build the Manchester Mark One, I'm thinking of you), but most people can't. And most people cannot write C well enough to outperform the software that the same person can write in a decent high level language.
Virtually no-one, now, can write anything sophisticated or complex in opcodes. Virtually no-one can do it even in assembler (yes, I know you did a little assembler project in CS101, but that really doesn't count). Yes, I know that a few rare geniuses can write exceedingly efficient fault free code in C or C++. Most complex programs written in C or C++, however, are too expensive in debugging and maintenance costs to outweigh any very small performance advantages they might have over high level languiages. Grow up, and live in the modern age. Toggling switches on the console, teletypes, punchcards, assembler and C are all history.
(Mind you, of course, there is some exceedingly bloated code around. I recently installed, on Windows, a Bluetooth device driver that was 60 Megabytes, which I found unbelievable... the fact that we have high level languages is no excuse for bloat or sloppy engineering practices.)
Re:Ask any grey beard. (Score:5, Funny)
I've been dabbling in Objective C. It's... interesting. I regret nothing... well, unless I have those dreams with the brackets. So many brackets! And the garbage! Piling up everywhere! Was it five references or six? Do I feel lucky? What? Where was I? Oh. Yeah, it's OK.
Re: (Score:3)
I've been dabbling in Objective C. It's... interesting. I regret nothing... well, unless I have those dreams with the brackets. So many brackets!
I think you'd really like Lisp - maybe tackle that next.
Re:Ask any grey beard. (Score:4, Informative)
The latest version of Objective C has automated reference counting, so garbage collection is no longer an issue.
Re: (Score:3)
Re: (Score:3)
Objective-C has 90% of the power of Ruby, with 90% of the static-compile-time checking of C++. I actually started an objective-c implementation of Rails (called Newm), but haven't had time to do a lot of work on it. Ruby developers waste half their lives writing tests for things a compiler could catch automatically. About 80% of Rails application bugs could be caught just by having decent compile-time type checking, which Objective-C provides.
Re: (Score:2)
What about ObjectiveC do you not like? Aside - if you leave a shallow answer like "the syntax", rather than actually giving a thought out reasoned answer about semantics, I personally will come around to your house with a trout to slap you.
Re: (Score:2)
All right... who knows where anonymous coward lives...
WORA.... (Score:3, Insightful)
Re:WORA.... (Score:5, Interesting)
The problem with WORA is that the interpreter has to both be present and consistent across all environments. It worked for Java, because Sun wrote all of the initial JVMs, and every such JVM conforms to the same spec. Even then, Java was for the desktop/server. Sun had to change to a new spec for mobile, which they recognized was a completely different playing field. The scope of WORA that Facebook wanted to apply wouldn't have worked even they were using Java.
Something as massive and as fractured as HTML5 where everybody "supporting" it has actually only implemented a portion of the standard and not the full thing, it's virtually impossible to get right. Not only this, but there needs to be a layer that changes elements based on device capability and type. This layer does not exist in the standard. Thus, WORA cannot and does not work for HTML5.
And to be honest, it may never work.
Re: (Score:2)
In Facebook's case, the problem with WORA is much larger than that. Because the interpreter must be consistent across all environments, it is difficult to take maximum advantage of features that do not exist everywhere. Not just the sorts of device capabilities that impact HTML5, e.g. screen size, but also device features, e.g. address book, built-in camera, etc. that cannot be taken advantage of from within a web app.
As a result of this, the Facebook app was never WORA. It was a custom, probably iOS-spe
Re: (Score:2)
Why does WORA have to be a scripting type language? How about a WORA complied language? I see no problem with having to recompile an application for different platforms. The gaming industry should've done this years ago for cross-platform games. One language, write once run anywhere with a simple recompile. I know it's been tried in the past and screwed up by (usually MS) someone wanting their own standard to be THE standard, but come on people, this is the 21st frigging century. It's well within our
Is that why it sucks? (Score:3)
Weird, their web browser app is what I use since their app sucks. Guess this is why?
C'mon (Score:5, Insightful)
They're having trouble returning a few hundred lines of text and 10 photos. Methinks HTML rendering speed is not even remotely their problem.
No. (Score:2, Insightful)
UI Rendering speed is exactly the same for native code and html elements. The reason is, guess what browsers do to show you lists, buttons, drop down boxes, etc?? They use *NATIVE* UI elements. It is plainly obvious you understand nothing on this topic.
The issue is UI *latency*. HTML based UI cause increased round trips from mobile devices to their data-centers creates a terrible experience for users when compared to native apps. Mobile devices already are worse off when it comes to network latency, and th
Re: (Score:3, Insightful)
at-least it would look the same everywhere.
And here we have the problem. Web pages are not supposed to look the same everywhere.
Yet PHBs trying to achieve that are what cause literally every problem in Web standardization.
Just serve me the information, and I'll render it how I like.
Quit obsessing about controlling my user agent!
Re: (Score:3)
Although that is pedantically true if you did all your own UI drawing using programmatic calls and did all your own layout work using something as complicated as the DOM and CSS, in practice, you're completely and totally wrong. The UI layout engine used for a native app is orders of magnitude faster. And this is w
Re: (Score:2)
A web app UI framework that actually integrates with IB? Wow. I may have to play with that.
Re: (Score:3)
what is proprietary about iOS? it's freebsd for ARM with a GUI and support for proprietary API's. Safari is webkit just like chrome
Re: (Score:2)
Actually, a bunch of the APIs aren't even proprietary. A bunch of it is just an evolution of an openly-developed standard, with two companies behind it, that was deployed on multiple operating systems and multiple hardware platforms, and that has an open source implementation today.
http://en.wikipedia.org/wiki/OpenStep [wikipedia.org]
http://www.gnustep.org/ [gnustep.org]
(Not all, sure. But a bunch.)
Device features unreachable through Safari (Score:2)
what is proprietary about iOS?
The cryptographic key for verifying what is allowed to run on one's own device.
support for proprietary API's
Some features of the device, such as the microphone and camera, can be reached only through these proprietary APIs, not through Safari.
Re:C'mon (Score:4, Informative)
This is about a browser, not a proprietary OS, and the fact that they have to communicate with back-end servers for several million users has nothing to do with HTML5 vs native. Facebook is having trouble, and it's most likely because the programmers assigned to the task weren't good enough.
There are HTML5 apps that look really good, for example, Fidelity has a nice app that looks sharp and is performant.
Now, personally, I'd rather write in native code than in HTML5, but that is a personal preference, not because HTML5 can't handle the task on iPhone.
Re: (Score:3)
I might buy that line of reasoning if I couldn't fire up the Facebook website on my phone and tablet and compare the speed with the app.
Re: (Score:2)
No, they're having problems getting a half baked open standard to support all the features of a proprietry OS, because as per usual, the WORA solution addresses the least common denominator, not the sum of all features.
Good start (Score:5, Insightful)
That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.
At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.
Re: (Score:2, Insightful)
That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.
At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.
And (this is the point, really) not just on IOS! Blaming the problems on html 5 and changing to old crufty Objective C sounds like a rationalization. An excuse used by executives to board members who don't know any better.
Re: (Score:2)
Why would anyone use old crufty ObjC when there's a nice modern runtime and language to use instead?
Oh, I get it... you're stuck in 1995. Hint: NextStep is history!
Re: (Score:3)
Because objc *has* a nice modern runtime, and is a nice modern language ;)
Wasn't there some guy behind the app originally? (Score:2)
....and he departed FB or said he was done with iPhone development or some other small-scale hubris?
Part of me thinks that FB doesn't really *care* if the iOS app works, they just want to know what platforms you use FB on and if they see regular use from an iDevice, they know that you fit in a specific demographic bucket of "iPhone owner".
Re: (Score:2)
yes, he used to work for Mozilla. explains everything
he thought he was da sh1t and the app was always buggy
Re: (Score:3)
The problem is that the Facebook engineers went too far.
In their hubris (not necessarily generally bad) they thought that they could literally create a very deep interface between their html code and the underlying native APIs. Essentially abstracting the underlying native APIs with a code interpreter that would allow their servers to send the same html to any device, and some additional stuff for those that had other features.
As usual, they started simple and everything worked, but then over a few months t
Comment removed (Score:5, Insightful)
Re: (Score:2)
It depends on exactly what it is you are doing, but generally speaking, native is usually noticeably faster. Even when rendering local content with a web view, you can usually see redraws and flickering where there wouldn't be any if you used native controls. You have to remember that these days, rendering a web page is actually a huge task, and this is a mobile platform, not a desktop PC. Mobile computing has come a long way in the past five years, but
WODE . . . Write Once . . . (Score:5, Funny)
Debug Everywhere . . .
Why does FB care about write-once run-anywhere? (Score:5, Insightful)
They are a multi-billion dollar company dealing with an app running on one of (if not the) most relevant and widely-used smartphones in the market. They should dedicate a team specifically for the iPhone. And if Apple changes the API every week, they would be wise to rewrite the app every week just to maintain that market.
I don't care for Facebook and have my issues with Apple, but this is just a business decision on ROI.
what what what? (Score:2, Insightful)
But... isn't html 5 the latest and coolest thing, and Objective-C some really old thing that Apple inherited from medieval times?
And and... hang on... wasn't the coolness of html 5 the excuse for Apple not supporting some old and crufty thing called Flash?
Re: (Score:3, Insightful)
This is just Facebook trying to blame their shoddy implementation on someone else.
None of the bugs and issues reported by users are HTML5 caused problems.
Re: (Score:3)
This is just Facebook trying to blame their shoddy implementation on someone else.
None of the bugs and issues reported by users are HTML5 caused problems.
(You are absolutely correct. I was being ironic.)
Re: (Score:2)
The coolness of HTML5 video (h.264), was one of the many reasons. And that works great on the iPhone.
Re: (Score:3)
FB can afford to piss away money on a proprietary app now that they're a multi-billion dollar company. The vast majority of companies can't. I just don't see a huge resurgence of native apps replacing web functionality. Very few companies have the resources to develop for multiple platforms like that, and you really can't afford to just ignore android, or whatever else comes out into the mobile world in 5 years.
WORA - Fortran (Score:2)
Write once, run anywhere? Didn't they say that about Fortran? Write it all in Fortran and get off my lawn.
Re: (Score:2)
the enemy of my enemy is my friend (Score:2)
Facebook is google's enemy
they are frenemies with Apple
why support HTML5 which also supports your enemy when you could make your frenemie's platform "better" with a native app and hurt your enemy
Android version (Score:5, Informative)
Does the Android version use HTML5 as well? Because it is beyond horrible. I can't figure out why the app would actually be SLOWER and harder to deal with than viewing their site on a browser, but somehow they have managed it.
Re: (Score:2)
My guess is that the problem is on Facebook's end and Michael Stonebreaker was on to something when he critiqued Facebook's database architecture: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ [gigaom.com]
So to compensate for some of those issues, they have to go to a more responsive UI.
Re: (Score:3)
Re: (Score:2)
The only reason i have the facebook app installed is it's integration to the share button in gallery/photos. If I'm going to browse the site I use the browser.
As long as they... (Score:4, Interesting)
But will it help? (Score:5, Interesting)
It seems to me that the Facebook app's issues are not so much about HTML5 performance, but rather the way that they handle transactions with their servers. The network performance of the app is atrocious. Look at the traffic of the iOS app and compare it to the Facebook mobile website. How many hundreds of XMLHTTPRequests do you think it should take to render a page?
There's nothing inherently wrong with the HTML5, it's their ludicrous network activity that kills the app.
Nothing wrong with HTML (Score:2)
Its just that using HTML to build "native" apps for iOS has been proven to be poor over and over again.
Apple just does not want ANY competitive technology to shine on iOS. They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden. Building HTML apps that can be easily ported to other platforms wasn't going to be something that worked better then native iOS apps built for the walled garden.
It comes down to whether you want to be cheap
Re: (Score:3)
They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden.
Having experienced Flash on Android, I think you're mistaken. And the fact that Adobe basically gave up on making it useable on mobile devices supports Apple's stated position.
Their product is inherently crappy. (Score:2)
Sure, many find it useful anyway, but theirs is not a technological problem.
iOS 6 FaceBook support (Score:5, Insightful)
Given that Apple is integrating FaceBook support into iOS 6 (I've got it on my phone right now, and the 'post' button works exactly as advertised), it seems to me that this is probably being done in no small part because Apple is doing a bunch of stuff in Obj-C anyway. I have no idea what the FB API stuff is like (or even if it's available to devs like me) but there's clearly *something* going on under the hood.
So Apple does some of the heavy lifting, and the FB programmers just piggyback off of it. At that point, why not switch?
Facebook App was Useless Anyway (Score:2)
Now, I have an Android phone so if it's remarkably different on iOS I could be off base here, but from what I saw of the app, it was exactly the same as the mobile web interface except that it also had access to your GPS and potentially camera. Having an app like Facebook turn on GPS as soon as I logged in was enough for me to limit myself to accessing it through the browser. *tightens tinfoil cap*
yay (Score:2)
This is exactly what Apple wanted. (Score:5, Interesting)
Apple's formula for success under iOS:
1. Control the hardware
2. Control the software
3. Make others do the work and because (1) and (2), you get to take a BIG cut of their business. No, not BIG... HUGE.
Part of (2) is to not allow any development that might result in GOOD write-once/run-anywhere software. Backing HTML5 is a perfect example. The amount of effort required to produce a decent product is just plain insane. Even big companies like Facebook can't do it. Little companies don't even try. In the end, damn near everybody who tries to deploy an application that runs on an iOS device comes to the same sad realization: cough up the dough or go home.
Products that actually worked, and worked well (e.g. Flash, Silverlight, etc.) were killed with feeble excuses like battery consumption and quality control. How the DoJ didn't launch an investigation into anti-competitive practices is a mystery to me. The "browser included in OS" investigation of Microsoft seems a pale shadow of the "you don't run software on iOS devices- despite the fact that their OWNERS want you to- unless you pay us a shiatload of money." /Bitter? You betcha.
Re: (Score:2)
New here?
Re: (Score:2)
Thank goodness. Every app that I see on my iPhone that uses HTML to be portable suffers horrible performance. This includes FB, but also the iTunes store. Over the past few months, the iTunes store has become almost useless on my iPhone 4. FB was among the worst, but it did recently get much faster when they apparently upgraded their servers. It's still crap, don't get be wrong, but it's a good deal better than it was a month ago.
Sounds like a problem with the iphone to me....
Re: (Score:2)
Re: (Score:2)
Maybe they should have wrote the iTunes in flash.
In this case, I'd bet it would be faster, assuming you could emulate flash.
Re: (Score:2, Offtopic)
Re:About time (Score:5, Interesting)
I think the problem with the Facebook "app" was that it didn't seem to store anything locally -- meaning every UI event involved a request over the internet, which does not make for a responsive UI.
Re: (Score:2)
so would a Cordova-based approach (where the html 'server' is located locally) make a much better user experience? ie, write a 'thick client' app using HTML technologies rather than a traditional web page that is squeezed into iOS size.
Re:About time (Score:4, Interesting)
This is definitely true. The Financial Times native app got replaced with a nearly-equivalent HTML5 "app". Safari asks for permission to store extra data locally, and then it generally feels pretty responsive (relative to other news apps, which in all honesty feel a bit bloated). I'm not sure how compatible it is with other platforms, though - it might have a bunch of really ugly ipad-specific hacks behind it, who knows.
Microphone and camera from HTML5 (Score:2)
Re: (Score:2)
They are not even talking about PHP or Ruby , this is app development using HTML 5 which can live on as a semi-native app on iOS which has nothing to do with server/network performance. BTW that moldy old C/C++ code is the reason why Ruby and PHP works in the first place.
Re: (Score:2)
Sounds like they're making the right decision, then. By moving to native code instead of doing most of their communication using XMLHttpRequest (presumably), they'll be in control over their caching behavior, which could make them better able to avoid being a memory pig. Also by using native code, they won't be running interpreted or JIT-compiled code, which means battery life should improve noticeably as well.